New syntax for string mixins

[Jonathan M Davis]

On Wednesday, December 15, 2010 11:27:47 Jacob Carlborg wrote:
> On 2010-12-14 21:44, Nick Sabalausky wrote:
> > "Jacob Carlborg"<doob at me.com>  wrote in message
> > news:ie8i8c$15f0$1 at digitalmars.com...
> > 
> >> On 2010-12-14 19:13, Nick Sabalausky wrote:
> >>> "Graham St Jack"<Graham.StJack at internode.on.net>   wrote in message
> >>> news:ie76ig$b2v$1 at digitalmars.com...
> >>> 
> >>>> What you are suggesting here seems to be a way to dramatically reduce
> >>>> the
> >>>> complexity of code that generates source-code and mixes it in. I think
> >>>> something like that is needed before this mind-bogglingly powerful
> >>>> feature
> >>>> of D can realise its potential.
> >>> 
> >>> I think a decent string-template library could probably come very close
> >>> to
> >>> the proposal without needing any language changes at all:
> >>> 
> >>> string get_set(T, string name)()
> >>> {
> >>> 
> >>>        return
> >>>        q{
> >>>        
> >>>            @type _ at name;
> >>>            
> >>>            @type @name ()
> >>>            {
> >>>            
> >>>                return _ at name;
> >>>            
> >>>            }
> >>>            
> >>>            @type @name (@type @name)
> >>>            {
> >>>            
> >>>                return _ at name = @name;
> >>>            
> >>>            }
> >>>        
> >>>        }.replace( ["@type": T.stringof, "@name": name] );
> >>> 
> >>> }
> >>> 
> >>> class Foo
> >>> {
> >>> 
> >>>        mixin(get_set!(int, "bar")());
> >>> 
> >>> }
> >>> 
> >>> There are definitely some things about the proposal that are better
> >>> than with this, but I just wanted to point out that the value of the
> >>> proposal should probably be evaluated against something roughly like
> >>> the above rather
> >>> than something that does a bunch of procedural string splicing.
> >> 
> >> The whole point of the idea was to get rid of the strings and the mixin
> >> expression (as it looks like to day).
> > 
> > While I'm not necessarily opposed to the idea of getting rid of the
> > strings, I guess I don't really see what improvement your proposal
> > provides other than not having to manually specify the mapping of
> > "replace what identifier with what data".
> > 
> > Getting rid of the "mixin" I see as a separate issue. We could just as
> > 
> > easily say that given the function "string get_set(...)":
> >      @get_set("int", "bar");
> >      or
> >      @get_set int bar;
> > 
> > ...Is shorthand for, or is even the new syntax for:
> >      mixin(get_set("int", "bar"));
> 
> That was my idea as well, that
> 
> @get_set("int", "bar");
> 
> could be translated into
> 
> mixin(get_set("int", "bar")); just like
> 
> just like scope statements are translated into try/catch/finally.

Honestly, I don't see much gain in using @ rather than mixin(). It's a little 
less typing, but that's it. And it precludes stuff like mixin("lhs " ~ op ~ " 
rhs") like happens all the time in overloaded operator functions.

- Jonathan M Davis