Jump to page: 1 2 3
Thread overview
DIP28, on properties, availabel for destruction as well
Feb 27, 2013
deadalnix
Feb 27, 2013
Jonathan M Davis
Feb 28, 2013
deadalnix
Feb 28, 2013
Chris Cain
Feb 27, 2013
Jacob Carlborg
Feb 28, 2013
deadalnix
Feb 28, 2013
Jacob Carlborg
Feb 28, 2013
deadalnix
Feb 28, 2013
Jacob Carlborg
Feb 28, 2013
deadalnix
Feb 28, 2013
Jacob Carlborg
Feb 28, 2013
angel
Feb 28, 2013
Artur Skawina
Feb 28, 2013
angel
Mar 01, 2013
deadalnix
Mar 02, 2013
Timon Gehr
Mar 02, 2013
deadalnix
Mar 02, 2013
deadalnix
Mar 02, 2013
Timon Gehr
Mar 13, 2013
deadalnix
Mar 13, 2013
Timon Gehr
Mar 14, 2013
deadalnix
Mar 14, 2013
Artur Skawina
Mar 14, 2013
deadalnix
Mar 14, 2013
Artur Skawina
Mar 14, 2013
Timon Gehr
Mar 14, 2013
Artur Skawina
Mar 13, 2013
Timon Gehr
Mar 14, 2013
deadalnix
February 27, 2013
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.
February 27, 2013
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
February 27, 2013
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
February 27, 2013
On 2013-02-27 16:46, 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.

What happens if you do:

auto a = b.setter = 3;

I see two alternatives:

A. It's rewritten to this:

auto __tmp = 3;
b.setter = 3;
auto a = __tmp;

B. It's rewritten to this:

b.setter = 3;
auto a = b.getter;

I prefer B.

What happens if you do:

struct Point
{
    int x;
    int y;
}

class Widget
{
    @property Point getter();
    @property Point setter(Point);
}

auto w = new Widget;
w.getter.x = 3;

I would prefer if that gets rewritten to:

Point __tmp = w.getter;
__tmp.x = 3;
w.getter = __tmp;

-- 
/Jacob Carlborg
February 28, 2013
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.
February 28, 2013
On Wednesday, 27 February 2013 at 20:09:51 UTC, Jacob Carlborg wrote:
> On 2013-02-27 16:46, 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.
>
> What happens if you do:
>
> auto a = b.setter = 3;
>
> I see two alternatives:
>
> A. It's rewritten to this:
>
> auto __tmp = 3;
> b.setter = 3;
> auto a = __tmp;
>
> B. It's rewritten to this:
>
> b.setter = 3;
> auto a = b.getter;
>
> I prefer B.
>

The proposal is to rewrite that to auto a = b.setter(3);

Its value is whatever the setter returns.

> What happens if you do:
>
> struct Point
> {
>     int x;
>     int y;
> }
>
> class Widget
> {
>     @property Point getter();
>     @property Point setter(Point);
> }
>
> auto w = new Widget;
> w.getter.x = 3;
>

Error, w.getter is not an lvalue.

> I would prefer if that gets rewritten to:
>
> Point __tmp = w.getter;
> __tmp.x = 3;
> w.getter = __tmp;

That would be an error as well, for the same reason.
February 28, 2013
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.
February 28, 2013
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
February 28, 2013
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.
February 28, 2013
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
« First   ‹ Prev
1 2 3