UFCS idea

[Jonathan M Davis]

On 2011-06-09 00:20, Andrew Wiley wrote:
> On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal <alex_dovhal at yahoo.com> wrote:
> > There have been several topics discussing UFCS recently. So here is one
> > more)
> > One idea about UFCS - mark UFCS argument with @, @_, or _ symbol,
> > e.g. you have some function:
> > void func(Type1 p1, Type2 p2);
> > 
> > and later call it:
> > fucn(a, b);  //or
> > a.func(@_, b);  //or
> > b.func(a, @_);
> > 
> > This way Timon Gehr's example:
> >    take(10,stride(2,cycle([3,2,5,3])));
> >    [3,2,5,3].cycle().stride(2).take(10);
> > 
> > would be written as this:
> >    [3,2,5,3].cycle(@_).stride(2, @_).take(10, @_);
> > 
> > Which is a little longer. On the other side this way benefits from:
> >  * UFCS is directly seen by both the programmer and compiler;
> >  * UFCS doesn't mix with member call syntax;
> >  * UFCS can be used for any type and for any argument, e.g.
> >  
> >    a.func(@, b) or b.func(a, @);
> >  
> >  * UFCS can be used for more than one argument: a.func(@_, @_~[1]);
> > 
> > What do you think?
> 
> I find it funny that @ was initially adopted for annotations, to be used
> similar to Java and Scala. I come from that world, and one of the rules for
> annotations is that they cannot directly alter the code the compiler
> outputs. You can add plugins to the Java compiler that use annotations to
> modify the AST before it's compiled, and you can use annotations for
> runtime bytecode generation or interpret them using reflection, but if you
> take unannotated code and annotated code and compile it (without altering
> the compiler), the generated code will not change.
> The idea was to make them a part of the language composed entirely of
> metadata (some of which was enforced to be correct by the compiler) that
> could be completely ignored if the programmer didn't want to use it.
> Now that D has taken up this syntax, we've done almost the opposite. @ is
> mostly used in situations where it changes the compiled code, changes the
> existing language,  and is in no way optional. We don't really support user
> defined metadata, and we can't use what annotations we have as metadata
> because only the compiler can actually use it. Most of the uses I've seen
> seem to be a way to cram more keywords into the language without adding
> more keywords.
> I've been holding in this sort of rant for a while, but in summary, my
> response is that unless the desired use for @ was defined radically
> differently by D when it was adopted (and, as far as I can tell, it
> wasn't), seeing another abuse of it just makes me feel slightly sick
> inside.

As it is, user-defined attributes can be added later using the @ syntax. True, 
all of the current uses of @ are for where we decided to save a keyword, but 
that doesn't stop user-defined attributes from using the syntax later. It just 
means that those that are currently defined will always be special.

Regardless, I see little point in using it for UFCS. If we want to 
specifically mark parameters for it, I think that the suggestion of using 
"this" makes a lot more sense. You wouldn't even have to change the grammar 
(unlike if you used @). You'd just change the semantic phase to treat "this" 
specially as a function parameter and not freak out about it being a keyword. 
Using @ would be a much bigger language change and for no gain whatsoever as 
far as I can see.

- Jonathan M Davis