DIP28, on properties, availabel for destruction as well

[deadalnix]

On Wednesday, 27 February 2013 at 17:56:10 UTC, Jonathan M Davis 
wrote:
> On Wednesday, February 27, 2013 16:46:37 deadalnix wrote:
>> Here come the sister of DIP27 : DIP28 
>> http://wiki.dlang.org/DIP28
>> .
>> 
>> It address specifically properties. A 3rd one is coming on
>> delegate. As for DIP27, the goal is to go aggressively for
>> simplicity.
>
> And what does this provide over DIP23 aside from the fact that 
> now it's
> impossible to get the address of a property function (which of 
> course is
> a problem)?
>

It doesn't have special cases.

As of taking the address of a property, we should simply allow 
the compiler to optimize away lambda when they are of the form :
a => fun(a);

when it make sens to do so. This is easy to recognize for the 
compiler.

Additionally, I don't think this is really a problem as it is 
asking to break the abstraction, plain and simple. If you need a 
function pointer, then it is likely that you shouldn't be using a 
property in the first place.

Every signle field access involve some operation, sometime even a 
complex one (TLS on OSX for instance). And you can't get a 
function pointer on that, and this haven't been a problem for 
anyone so far. The compiler propose some routines to interact 
with data, and properties allow the user to propose its own.