Permalink
Reply
Recently we've discussed syntax solutions to ref not applying to a variable/parameter when those are of function pointer type:
https://issues.dlang.org/show_bug.cgi?id=2753
ref is a function attribute, so this problem is easier to solve. Also it is not allowed after the parameter list because conceptually it applies to the return value.
However, there is another case of missing syntax for an unimplemented feature. scope would be useful to apply to the return value of a function. Currently scope is disallowed on functions except for methods or delegates, where it applies to this or the context. There are cases where it would be useful to apply to the return value - e.g. for List.front here:
https://issues.dlang.org/show_bug.cgi?id=17934
Elem elem;
{
auto l = list();
elem = l.front; // should error
// destructor called
}
And for S.fp here:
https://forum.dlang.org/post/mqyqlieghqwsinbqiqbp@forum.dlang.org
int* p;
{
auto lf = S(5);
p = lf.fp; // should error
// destructor called
}
Syntax solutions proposed to fix the ref problem are:
- Parenthesized type syntax - https://forum.dlang.org/post/fnfuczxfyjpyespactjt@forum.dlang.org
- leading function pointer type syntax - https://forum.dlang.org/post/qngjoxgihmcsvoprnanb@forum.dlang.org
- trailing return type syntax - https://forum.dlang.org/post/iveapbodjzgqfjkujsop@forum.dlang.org
The first two have PRs. I think only the latter fixes the scope problem. A simpler fix would be this ordering:
Type ReturnStorage? Identifier Parameters
Where ReturnStorage is ref or scope.
T scope ref func_name();
Using parentheses just for the storage class(es) would work too:
(scope ref) T func_name();
Also, solving the problem generally could be useful in the future if we want any other storage classes to apply to the return value rather than the function or the parameter.
