DIP4: Properties

[Daniel Keep]

Nick Sabalausky wrote:
> "Daniel Keep" <daniel.keep.lists at gmail.com> wrote in message 
> news:h4i0tu$hig$1 at digitalmars.com...
>> Look at it from a practical standpoint: it *would* be nice to have
>> dedicated syntax, but Walter *is opposed to it*.  He doesn't see the
>> need for it.
>>
> .....
>> Some improvement is better than none.  Sometimes you have to compromise.
>> I don't think we should ignore or demonise viable alternatives because
>> they're not what we specifically wanted.
> 
> I suppose you have a good point. Although I felt like I was compromising 
> plenty just with being willing (if necessary) to abandon the automatic 
> internal storage... :/  (I really want that! :) )
> 
> I am convinced though, if properties get done in this Walter-friendly 
> manner, it'll become yet another in the list of prospective user's 
> complaints about D. "Yea, I looked at D. Have you seen the syntax for 
> creating properties? OMG, what were they thinking?!" 

Actually, what I'd like to see is this syntax:

mixin properties!
q{
    int foo = 42
    {
        get;
        set { notify(); storage = value; }
    }
};

The only reason we HAVE to use a string mixin here is that you can't
have protection attributes in a mixin template; they get applied to
within the scope of the template, not the scope of where they're being
mixed in.

Pity we can't do: `private(scope) T storage;` or somesuch to escape the
protection...

As for parsing the string, I suspect that it's possible, but all my
experiments into CTFE-based parsing of D code has shown it to be
incredibly fiddly and painful.