UFCS idea

[Jonathan M Davis]

On 2011-06-09 12:01, Andrew Wiley wrote:
> On Thu, Jun 9, 2011 at 1:32 AM, Jonathan M Davis <jmdavisProg at gmx.com>wrote:
> > 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.
> 
> My point wasn't that the syntax should be different (it should definitely
> be the same), my point was that we stopped short of fully implementing
> annotation support and that the result seems to be significantly less than
> ideal.

Well, adding user-defined attributes would be purely an additive change and 
wouldn't break any code, so there's probably a decent chance that we'll be 
able to get it added to D2 at some point. But there are still plenty of more 
core issues that need to be addressed before we look at adding features like 
that, so I don't think that it's all that big a deal that we don't have them 
yet. I think that there's a good chance that we will eventually.

- Jonathan M Davis