On Wednesday, 27 February 2013 at 15:46:38 UTC, 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.
I like both this one and DIP27. But I do think it is way too late
for D2.
Lars

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)?
- Jonathan M Davis

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.

On Thursday, 28 February 2013 at 02:56:40 UTC, deadalnix wrote:
> 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.
+1. Properties (from what I've seen) are suppose to be
effectively indistinguishable between a field. If you're taking
the address of a property hoping to get the function address,
this is a clear violation of that.
For instance, if I wrote some code like this:
...
auto myFun = &b.front;
...
And I expected to get a function pointer from that, it would be a
clear violation of what ".front" means (or, is intended to
mean...) and it would break on many ranges because many of them
are implemented s.t. front is actually a field.

On 2013-02-28 04:00, deadalnix wrote:
> The proposal is to rewrite that to auto a = b.setter(3);
>
> Its value is whatever the setter returns.
Then setters always must return a value. I think it would be better to
have the compiler rewrite the expression to return what the getter returns.
> Error, w.getter is not an lvalue.
Then you cannot freely change a field to a property.
> That would be an error as well, for the same reason.
That should have of course looked like:
w.setter = __tmp;
If this rewrite is not done then again, you cannot freely change a field
to a property.
--
/Jacob Carlborg

On Thursday, 28 February 2013 at 08:02:05 UTC, Jacob Carlborg
wrote:
> On 2013-02-28 04:00, deadalnix wrote:
>
>> The proposal is to rewrite that to auto a = b.setter(3);
>>
>> Its value is whatever the setter returns.
>
> Then setters always must return a value. I think it would be
> better to have the compiler rewrite the expression to return
> what the getter returns.
>
Must is not appropriate here, as it isn't an obligation at all. I
don't really see what is the concern here.
If the function is simple, then it will be inlined and unused
returned values can be optimized away. If the function is
complex, the cost of returning something when not needed will be
negligible anyway.
What is your concern here ?
>> Error, w.getter is not an lvalue.
>
> Then you cannot freely change a field to a property.
>
You can return an lvalue. But you example was returning an
rvalue; so it is an error in this case.

On 2013-02-28 09:21, deadalnix wrote:
> Must is not appropriate here, as it isn't an obligation at all. I don't
> really see what is the concern here.
>
> If the function is simple, then it will be inlined and unused returned
> values can be optimized away. If the function is complex, the cost of
> returning something when not needed will be negligible anyway.
>
> What is your concern here ?
My concern here is setters that doesn't return a value. They won't work
with chained assignments. Another thing that will break when changing a
filed to a property.
--
/Jacob Carlborg