DIP25 draft available for destruction

[Timon Gehr]

On 02/06/2013 08:12 PM, Andrei Alexandrescu wrote:
> On 2/6/13 1:39 PM, Benjamin Thaut wrote:
>> Am 06.02.2013 18:50, schrieb Andrei Alexandrescu:
>>> On 2/6/13 12:40 PM, Benjamin Thaut wrote:
>>>> So the &value expression would only be left for taking addresses of
>>>> functions? Wouldn't it make more sense to do it the other way around?
>>>> E.g. create some utilty function that is only there for taking the
>>>> address of functions and disallowing to do so by using &func?
>>>
>>> I don't think that would work without adding new keywords.
>>>
>>> Andrei
>>>
>>
>> Whats so bad about adding a new keyword for this?
>
> This is an ill-posed question. A keyword should justify its utility, not
> prove it doesn't harm.
>
>> I fear that newcomers will find taking addresses pretty inconsistens if
>> we implement this proposal. Because the language will have the take
>> address operator "&" they know from c++, but it only works in some
>> special cases. For all other cases addressOf has to be used. It would be
>> much more consistent if you could use the "&" operator for everything
>> but taking the address of a function. That would be more consistent in
>> my opinion.
>
> It would be more consistent with C++, but less so with the notion of
> safety. I find it very consistent that all uses of &expression are safe,
> and this is the kind of consistency Walter and I believe is worth aiming
> for.
>

So you are saying this should compile?:

struct S{
     int x;
     int foo()@safe{ return x; }
}

int delegate()@safe foo()@safe{
     S s;
     return &s.foo;
}


>> Lately I'm getting the feeling that D 2.0 is becoming a collection of
>> hacks to workaround issues which could be solved by adding new keywords
>> or doing other major changes. (like all the stuff that starts with __)
>
> I can't help how you feel, but I think you're wrong here and I don't
> know what other cases you're referring to.
>

+1.