On Sun, 03 Feb 2013 12:58:21 -0500, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 02/03/2013 06:47 PM, Steven Schveighoffer wrote:
>> On Sun, 03 Feb 2013 12:36:10 -0500, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> On 2/3/13 7:40 AM, kenji hara wrote:
>>>> 2013/2/3 Steven Schveighoffer <schveiguy@yahoo.com
>>>> <mailto:schveiguy@yahoo.com>>
>>>>
>>>>     I have a possible suggestion to fix this within your proposal:
>>>>
>>>>     @property on single-arg free functions ONLY enables a setter mode,
>>>>     it does not work as a UFCS getter.
>>>>
>>>>   [snip]
>>>>
>>>> I was thinking the exact same thing.
>>>
>>> Then we can't make this work:
>>>
>>> @property ref T front(T[] array) { return array[0]; }
>>>
>>> unittest
>>> {
>>>     auto a = [ 1, 2, 3];
>>>     auto b = a.front;
>>> }
>>
>> ref T front(T[] array) { return array[0]; }
>>
>> // same unittest
>>
>
> different unittest:
>
> unittest{
>      auto a = [()=>2, ()=>3, ()=>4];
>      assert(a.front()==2);
> }

OK, so that is not good.  I think the current DIP23 idea should be sufficient, no global properties.

-Steve

On 2/3/13 1:32 PM, TommiT wrote:
> On Sunday, 3 February 2013 at 18:28:06 UTC, Andrei Alexandrescu wrote:
>> [..]
>> This is a matter of visibility. The presence of a member precludes any
>> UFCS. Won't compile. Same for the 2nd example.
>
> Just to be perfectly clear, it must be that this wouldn't compile
> either, right?
>
> struct S
> {
> int _n;
>
> @property int prop() const
> {
> return _n;
> }
> }
>
> @property void prop(ref S s, int n)
> {
> s._n = 42;
> }
>
> void main()
> {
> S s;
> s.prop = 10;
> }

Nope.

Andrei

On Sun, 03 Feb 2013 13:42:57 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 2/3/13 1:32 PM, TommiT wrote:
>> On Sunday, 3 February 2013 at 18:28:06 UTC, Andrei Alexandrescu wrote:
>>> [..]
>>> This is a matter of visibility. The presence of a member precludes any
>>> UFCS. Won't compile. Same for the 2nd example.
>>
>> Just to be perfectly clear, it must be that this wouldn't compile
>> either, right?
>>
>> struct S
>> {
>> int _n;
>>
>> @property int prop() const
>> {
>> return _n;
>> }
>> }
>>
>> @property void prop(ref S s, int n)
>> {
>> s._n = 42;
>> }
>>
>> void main()
>> {
>> S s;
>> s.prop = 10;
>> }
>
> Nope.

He means "Nope it wouldn't compile" in case that was confusing ;)

In general, functions must be overloaded within the same visibility level/scope.  If there is one overload at a level, ALL overloads must exist at that level, or they are not seen.

-Steve

On 02/03/2013 06:44 PM, Andrei Alexandrescu wrote:
> On 2/3/13 10:16 AM, Steven Schveighoffer wrote:
>> Let's go with the current proposal, and I will address the __traits
>> mechanism separately.
>
> Yes, __traits is a nice hatch if we discover we find we can't do
> something. Hopefully we won't find any, or just one.
>
> Andrei

__traits is a lot cleaner than assigning meaning to parentheses.

On 02/03/2013 06:38 PM, deadalnix wrote:
> On Sunday, 3 February 2013 at 17:37:03 UTC, Andrei Alexandrescu wrote:
>> In the proposal &a.b gets the delegate of a property.
>>
>
> :facepalm:

+1.

On 2/3/13 12:34 PM, Andrei Alexandrescu wrote:
> On 2/3/13 7:37 AM, kenji hara wrote:
[snip]

Copied your unittests with changes and explanations: http://wiki.dlang.org/DIP23#unittest. Please take a look and let me know of what you think!

For now I conservatively disallow top-level properties with 0 parameters. I think we can allow them later if there's a strong need. Top-level properties with 1 argument are always getters.

We need a bunch more with unittests that return callable entities.


Andrei

On 2/3/13 11:34 AM, Johannes Pfau wrote:
> You have to consider cases though where you have both a setter and a
> getter returning a 'ref value'.
>
> @property ref int value();
> @property void value(int new);

For now I disallow 0-parameter top level properties. This is a good argument for keeping things that way.

> * Is it valid to define both at the same time?
> * Which one is used for assignment etc?
>
>>> * Is taking ref values in the setter OK?
>>
>> How do you mean that?
>
> @property int value(ref int new);
>
> IIRC that was just meant to complement the "is returning ref OK".
> Usually nothing bad can happen. Although the ref parameter could be
> converted into a pointer with some nasty tricks it's probably not the
> job of the language to prevent that.

Yah, there should be no restrictions there.


Andrei

On 2/3/13 11:28 AM, Steven Schveighoffer wrote:
> This sounds good. It might be a bit confusing, but nice in the fact that
> &(a.b) always means address of whatever b returns, whether it is a field
> or property.

Yah, this is a good rule of thumb for generic code.

Note that there's a subtlety in the expression "&expr.name". This is not precedence, just use of punctuation to express a unit. Attempting to decompose it by inserting parens yields different things altogether: &(expr.name) and (&expr).name are not mere redirections of precedence.

>> @property int foo(); // error
>> @property int goo(int); // fine, assume a getter for int
>
> I think this is a possible solution, and I can live with that, I'm
> fairly certain that some people use global properties currently, so they
> will not be too happy.

Yah, let's see how this restriction pans out.

>> No. Templated member variables are not allowed either.
>
> Wait, what? I don't like this idea. Why should this not be allowed:
>
> @property void x(T)(T t) {_x = to!(typeof(_x))(t);}

Yah, I misspoke. Properties can be templated subject to the other restrictions.

Andrei

On 2/3/13 11:28 AM, kenji hara wrote:
> 2013/2/4 Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org
> <mailto:SeeWebsiteForEmail@erdani.org>>
>
>     We need to add this to the proposal. There are two schools of
>     thought here:
>
>     1. Make properties emulate regular variables as much as possible. In
>     that case &a.p is the same as &(a.p), i.e. it applies to the
>     returned value. (One counter-argument here is that properties should
>     seldom return a reference because that breaks encapsulation.)
>
>     2. Allow people to do whatever they need to do without much
>     aggravation. In that case &a.p obeys the normal rules of taking a
>     method's address, and &(a.p) applies to the returned value.
>
>     I favor (2) and put it in http://wiki.dlang.org/DIP23. Will talk to
>     Walter.
>
>
> I have thought about the problem, and filed an enhancement.
> http://d.puremagic.com/issues/show_bug.cgi?id=9062
>
> But, Walter disagreed against it.
> http://d.puremagic.com/issues/show_bug.cgi?id=9062#c13
>
>   Kenji Hara

Now that an overhaul is on the table, that warrants a second look.


Andrei

On Sun, 03 Feb 2013 14:42:17 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 2/3/13 11:34 AM, Johannes Pfau wrote:
>> You have to consider cases though where you have both a setter and a
>> getter returning a 'ref value'.
>>
>> @property ref int value();
>> @property void value(int new);
>
> For now I disallow 0-parameter top level properties. This is a good argument for keeping things that way.

I think Johannes' argument applies to non-global properties.

struct X
{
   private int _val;
   @property ref int value() { return _val;}
   @property void value(int newv) { _val = newv; writeln("in setter!");}
}

So should setting 'value' call the specific setter, or call the getter and just write it?

My vote would be to call the setter, since it wouldn't exist if the user didn't want to hook that call.

However, it certainly begs the question, why would anyone return ref if they want to hook setting?  One could always do this:

void foo(ref int v) {v = 5;}
X x;
foo(x.value);

I think it's still too early to make any assumptions at this point.  Someone may find a good reason for that, and it's certainly just easier to allow code that is already valid than it is to come up with a reason to have an error.

-Steve