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.
