Date: Thu, 13 Jul 2023 18:49:41 +0000
Thank you for the reply, Arthur
> I think it's reasonable to say that the latter are all "out of scope" for this proposal, but I'd say so explicitly. (IOW, this proposal isn't adding any new signatures; it's just regularizing the syntax by which today's valid signatures can be expressed.)
I would agree. Let's adapt an old mantra and ensure this proposal has a single well-defined purpose. But I expect we're on the same page here, and stating it explicitly quells concerns which may arise on a first reading of the idea.
> I think the return type should be deduced as usual from the "invisible return statement" in the invisible body of the defaulted function; and then after that deduction, the compiler should reject any return type that isn't exactly `X&`. I would not tie the well-formedness of the declaration to the exact syntax `auto&`.
I like this idea a lot. My big trepidation when proposing the idea was that it could end up adding yet another special case and specific rule to a set of functions which already have a lot of special cases and specific rules, but I was sufficiently unskilled in standardese to be able to find a nice, simple under-the-hood rule outside of the desired syntax I wanted. This would easily resolve potential issues with comparison operators, as you say, plus the apparent ambiguity in whether decltype(auto) is a valid return type for those functions.
> Have you looked into proposed wording for all this? Is it just replacing one sentence with another?
I'm no language lawyer but from what I can tell, the assignment operator issues arise from this clause in [dcl.fct.def.default]:
> " if F1 [the explicitly defaulted operator] is an assignment operator, and the return type of F1 differs from the return type of F2 [the implicitly generated operator] or F1's non-object parameter is not a reference, the program is ill-formed"
Regarding operator==, [class.eq] specifies directly that an explicitly defaulted operator== shall have declared return type bool, and [class.compare.secondary] does the same for the other comparison operators.
In terms of wording, I would say the likely change would to be to add words to the effect of your suggested rule to [dcl.fct.def.default]. I'm not familiar enough with how the standard is written to know whether it is best to explicitly state that this also applies to cases where a function's return type is pre-defined per the standard, or leave that as a consequence of the rule which doesn't need stating. I would also update the corresponding points for equality and comparison, perhaps to state that the function must return bool rather than that it must declare bool as its return type. It might be worth being careful on the specifics there - it would be all too easy to create some notion of "acceptable return type" for a function which could balloon into a new piece of standard language which needs applying across the entire document. I'm happy to defer to others' expertise on the matter, but I believe this should effect the desired change with minimal impact on the surrounding language.
> I'd be happy to coauthor; let me know.
I'd like that. This is my first time making a proposal for the language so I'd greatly appreciate help from more experienced hands on the matter. Just let me know the best way to get the ball rolling on collaboration and we'll see what we can do
> I think it's reasonable to say that the latter are all "out of scope" for this proposal, but I'd say so explicitly. (IOW, this proposal isn't adding any new signatures; it's just regularizing the syntax by which today's valid signatures can be expressed.)
I would agree. Let's adapt an old mantra and ensure this proposal has a single well-defined purpose. But I expect we're on the same page here, and stating it explicitly quells concerns which may arise on a first reading of the idea.
> I think the return type should be deduced as usual from the "invisible return statement" in the invisible body of the defaulted function; and then after that deduction, the compiler should reject any return type that isn't exactly `X&`. I would not tie the well-formedness of the declaration to the exact syntax `auto&`.
I like this idea a lot. My big trepidation when proposing the idea was that it could end up adding yet another special case and specific rule to a set of functions which already have a lot of special cases and specific rules, but I was sufficiently unskilled in standardese to be able to find a nice, simple under-the-hood rule outside of the desired syntax I wanted. This would easily resolve potential issues with comparison operators, as you say, plus the apparent ambiguity in whether decltype(auto) is a valid return type for those functions.
> Have you looked into proposed wording for all this? Is it just replacing one sentence with another?
I'm no language lawyer but from what I can tell, the assignment operator issues arise from this clause in [dcl.fct.def.default]:
> " if F1 [the explicitly defaulted operator] is an assignment operator, and the return type of F1 differs from the return type of F2 [the implicitly generated operator] or F1's non-object parameter is not a reference, the program is ill-formed"
Regarding operator==, [class.eq] specifies directly that an explicitly defaulted operator== shall have declared return type bool, and [class.compare.secondary] does the same for the other comparison operators.
In terms of wording, I would say the likely change would to be to add words to the effect of your suggested rule to [dcl.fct.def.default]. I'm not familiar enough with how the standard is written to know whether it is best to explicitly state that this also applies to cases where a function's return type is pre-defined per the standard, or leave that as a consequence of the rule which doesn't need stating. I would also update the corresponding points for equality and comparison, perhaps to state that the function must return bool rather than that it must declare bool as its return type. It might be worth being careful on the specifics there - it would be all too easy to create some notion of "acceptable return type" for a function which could balloon into a new piece of standard language which needs applying across the entire document. I'm happy to defer to others' expertise on the matter, but I believe this should effect the desired change with minimal impact on the surrounding language.
> I'd be happy to coauthor; let me know.
I'd like that. This is my first time making a proposal for the language so I'd greatly appreciate help from more experienced hands on the matter. Just let me know the best way to get the ball rolling on collaboration and we'll see what we can do
Received on 2023-07-13 18:49:44