0002692: Ballot comment #79: Default argument values in function prototype and implementation

Notes
(0007990) shalom (manager) 2009-04-13 07:16	I don't know whether this comment was intended to refer to class methods (see 0002385, 0001584, 0002451) or interface methods

(0008036) shalom (manager) 2009-04-19 00:56 edited on: 2009-04-27 01:27	13.5.3 does not talk about out-of-block function declarations. The comment uses the term "out-of-block". This term is used with respect to class methods in 8.23, so apparently that was the context of the comment. 8.23 does not discuss this point explicitly, it says, "The out-of-block method declaration shall match the prototype declaration exactly; the only syntactical difference is that the method name is preceded by the class name and the class scope resolution operator ::." 8.19, on Virtual methods, says, "when subclasses override virtual methods, they shall follow the prototype exactly by having matching return types and matching argument names, types, and directions. It is not necessary to have matching default expressions, but the presence of a default shall match." See 0002451 and the referenced discussions on the SV-EC reflector, indicating that there indeed has been confusion on this, and discussion about what the LRM should say. For interface methods, 25.7 says, "If a default argument value is needed in a subroutine call, it shall be specified in the prototype. If an argument has default values specified in both the prototype and the declaration, the specified values need not be the same, but the default value used shall be the one specified in the prototype." This indicates that if a default is specified in the prototype, it is not required to be specified in the implementation as well. I think this issue should move to SV-EC.

(0008103) mmaidment (manager) 2009-05-03 23:32	On April 27, 2009 the SV-BC reviewed the issue and unanimously agreed that this issue is better suited for SV-EC.

(0008437) Steven Sharp (developer) 2009-06-01 13:18	I believe that the LRM is clear. It says that the only syntactical difference for an out of block declaration is the class name ::. Since the default is part of the syntax, it cannot be different. I agree that it would be convenient to allow the default to be left off of the out of block declaration, and could support such a change. But the current LRM seems clear in not allowing this. Section 8.19 says that the virtual method overrides shall follow the prototype exactly, but continues to say in what way they must match (return types, and matching argument names, types and directions.) It explicitly says that the defaults need not match. Virtual methods are a different situation from an out of block declaration, so the rules need not match. In an out of block declaration, you are re-declaring the same subroutine. With a virtual method, you are declaring a different implementation. Though the LRM does not make this clear, I have inferred that the default is taken from the implementation actually called (i.e. the default is "virtual"). The reference in 25.7 is also not talking about an out of block declaration. It is talking about interface import task/function declarations. It does not directly conflict with the rule for out of block declarations. I think it would be better if the same rules were used for both, but the rules seem to be clear for both. So I disagree with the statement "This indicates that if a default is specified in the prototype, it is not required to be specified in the implementation as well." This is true for an interface task/function. That does not make it true for an out of block declaration. These are different constructs whose rules have been specified separately and differently. I would be fine with changing the rules for out of block declarations to match interface tasks/functions. I would be fine with changing both rules to allow leaving the default off of the implementation but not allow mismatching default values. But I think the current LRM is clear that for an out of block declaration, the default values must match the prototype.

(0008441) shalom (manager) 2009-06-02 05:14	When I wrote "This indicates that if a default is specified in the prototype, it is not required to be specified in the implementation as well," I was talking only about the meaning in 25.7.

(0008467) Steven Sharp (developer) 2009-06-08 12:37	The SV-EC believes that the LRM is already clear on this matter. In 8.23 the LRM says that the only syntactical difference for an out of block declaration is the class name :: syntax. Since the default is part of the syntax, it cannot be different. The SV-EC may consider relaxing this requirement in a future revision of the LRM. However, there is not sufficient time to work out the details of this for the current LRM.

(0008536) mehdi_mohtashemi (manager) 2009-06-13 18:35	SV-EC conference call on June 8th 2009 unanimously approved 'no change required' for mantis 2692 [ballot id #79].

(0008707) Dave Rich (manager) 2009-07-01 10:41	The Champions have voted unanimously to approve this issue on June 29, 2009

(0008846) Dave Rich (manager) 2009-07-02 15:16	The P1800-2009 Working Group approved the resolution of this issue as no change required.

Issue History
Date Modified	Username	Field	Change
2009-04-13 07:08	shalom	New Issue
2009-04-13 07:08	shalom	Type	=> Clarification
2009-04-13 07:09	shalom	Description Updated
2009-04-13 07:09	shalom	Issue Monitored: shalom
2009-04-13 07:09	shalom	Relationship added	child of 0002685
2009-04-13 07:16	shalom	Note Added: 0007990
2009-04-13 07:16	shalom	Relationship added	related to 0002385
2009-04-13 07:16	shalom	Relationship added	related to 0001584
2009-04-13 07:16	shalom	Relationship added	related to 0002451
2009-04-19 00:56	shalom	Note Added: 0008036
2009-04-27 01:27	shalom	Note Edited: 0008036
2009-05-03 23:32	mmaidment	Note Added: 0008103
2009-05-03 23:32	mmaidment	Category	SV-BC => SV-EC
2009-05-09 21:48	shalom	Relationship deleted	child of 0002685
2009-05-11 09:58	Neil Korpusik	Relationship added	child of 0002736
2009-05-18 02:56	Daniel Mlynek	Issue Monitored: Daniel Mlynek
2009-06-01 13:18	Steven Sharp	Note Added: 0008437
2009-06-02 05:14	shalom	Note Added: 0008441
2009-06-08 12:37	Steven Sharp	Note Added: 0008467
2009-06-13 18:35	mehdi_mohtashemi	Note Added: 0008536
2009-06-13 18:35	mehdi_mohtashemi	Status	new => resolved
2009-06-13 18:35	mehdi_mohtashemi	Resolution	open => no change required
2009-07-01 10:41	Dave Rich	Note Added: 0008707
2009-07-01 10:49	Dave Rich	Note Added: 0008758
2009-07-01 12:30	Dave Rich	Note Deleted: 0008758
2009-07-02 15:16	Dave Rich	Note Added: 0008846
2009-07-02 15:19	Dave Rich	Status	resolved => closed
2010-05-11 14:12	Jonathan Bromley	Relationship added	related to 0003078
2010-07-14 14:31	Thomas R Alsop	Relationship added	related to 0003105