Template args to UDA's

Jonathan M Davis jmdavisProg at gmx.com
Tue May 28 19:15:07 PDT 2013


On Wednesday, May 29, 2013 11:28:06 Manu wrote:
> On 29 May 2013 11:18, Kenji Hara <k.hara.pg at gmail.com> wrote:
> > But I can agree that is a little not good from human sense. I know a
> > related issue.
> > 
> > struct S {
> > 
> > immutable int foo() {} // immutable is prefix attribute (==storage
> > 
> > class)
> > }
> > 
> > In above, `immutable` would be applied to the declaration `foo`, not its
> > return type `int`.
> > 
> > But, changing semantics would break much existing code. Your enhancement
> > belongs same area. We need to get agreement of D programmers first.
> 
> Yeah, that's a good point, I've never liked that ambiguity.
> I always write: immutable(int) foo() {}
> Otherwise I never really know what to expect.

Well, it's not actually ambiguous at all. It's just undesirable. If the const, 
immutable, or inout uses parens around the return type, then it's the return 
type which is const, immutable, or inout. In all other cases, it's the 
function (and thus the this pointer). So, it's completely clear if you know 
the rules, but the rules suck. Unfortunately, if function attributes which 
could affect the return type could only go on the right (as is the case with 
C++), then those function attributes would be inconsistent with the others, 
and Walter doesn't like that. Enforcing that all function attributes always go 
on the right would fix that, but I expect that that's too different from C++, 
Java, etc. for that to have ever been acceptable, and at this point, it would 
break too much code for Walter to agree to change it.

- Jonathan M Davis


More information about the Digitalmars-d mailing list