UFCS idea

[Jonathan M Davis]

On 2011-06-09 01:15, Andrew Wiley wrote:
> On Thu, Jun 9, 2011 at 12:46 AM, Jonathan M Davis 
<jmdavisProg at gmx.com>wrote:
> > 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.
> 
> This is the difference in philosophy at the core of my general unhappiness.
> When Java officially added annotations, they were designed and built to be
> used for user-defined metadata. We added "Property" to the grammar,
> celebrated that we had them too, then stopped. The result is that we're
> throwing around @ as an excuse for language keywords and boasting about how
> we have annotations when, by the definition of any other language, we
> simply don't.
> I guess the best answer from where I'm standing is to start throwing around
> possible syntaxes for annotation declarations and references to them in
> compile-time reflection. I just really hope this gets in to D2, so we
> aren't permanently stuck with "fake annotations."

I don't really see anything wrong with leaving the current @ attributes as 
they are and then just using @ for user-defined attributes as well. There will 
just be a set of attribute names which are reserved by the compiler. All that 
using a different syntax for user-defined attributes would buy you would be 
that you could use the attribute names that the compiler has reserved - safe, 
trusted, system, and property. And that isn't exactly a huge gain. We might as 
well just use @ for user-defined attributes as well.

- Jonathan M Davis