On 02/03/13 16:04, Steven Schveighoffer wrote:
> On Sun, 03 Feb 2013 08:04:10 -0500, Timon Gehr <timon.gehr@gmx.ch> wrote:
> 
>> T delegate() f = &a.prop -> auto f = ()=>a.prop;
>> T delegate(T) f = &a.prop -> auto f = (T x)=>a.prop=x;
> 
> I don't like this solution.  You are creating a dummy delegate function, and moving the stack frame into the heap, just so you can get a delegate to an already existing function.

Not really, it just needs to be specced properly. There's already a similar
issue with lazy args, and the natural solution is the same.
A trivial "{ return any_kind_of_hidden_delegate; }" lambda is functionally
equivalent to a "cast(delegate)any_kind_of_hidden_delegate" expression. The
"optimization" just needs to be mandated, so that you can rely on the "real"
delegate being forwarded (ie the .funcptr should be the real one and such
lambda shouldn't trigger heap allocation).

artur

On Sunday, 3 February 2013 at 15:48:00 UTC, Johannes Pfau wrote:
>> -----------
>> In order to use the assignment operator "=" property-style, the
>> @property annotation MUST be used.
>> -----------
>
> There's a example on the page though which contradicts this:
>
> static int x;
> ref int fun1() { return x; }
> fun1 = 42;

That example has nothing to do with properties. It's just:

static int x;
ref int fun1() { return x; }
fun1() = 42;

...except that the empty parens were omitted (which is allowed there).

On Sun, 03 Feb 2013 10:31:31 -0500, deadalnix <deadalnix@gmail.com> wrote:

> On Sunday, 3 February 2013 at 15:16:30 UTC, Steven Schveighoffer wrote:
>> But the spirit of the proposal seems to suggest that for all intents and purposes, a property's type is the type of it's return value.
>>
>
> If you want a function, then just don't annotate with @property. The whole point of property is that it doesn't behave like a function.

That is not the point of properties.  The point of properties is to have hooks for field setting and getting.  They necessarily behave like functions.

-Steve

On Sun, 03 Feb 2013 10:56:50 -0500, kenji hara <k.hara.pg@gmail.com> wrote:

> 2013/2/4 Steven Schveighoffer <schveiguy@yahoo.com>
>>
>> ref int foowrap() { return foo;}
>> int *x = &foowrap();
>>
>
> One liner version:
>
> int* x = ((ref x) => &x)(foo);

That looks better than mine, it takes a bit to understand it :)  It can be written into a global function:

T *addressOf(T)(ref T t) {return &t;}

I think this should actually work:

int *x = foo.addressOf;

>> Let's go with the current proposal, and I will address the __traits
>> mechanism separately.
>>
>
> It seems to me that is an overkill.

I have other ideas for such a feature, which map into something I've wished for a long time.  You will see.

-Steve

On 2/3/13 5:14 AM, Johannes Pfau wrote:
> "If a function returns a reference, then assignment through the
> paren-less call should work: "
>
> This is the only part where I would disagree. Why is this special rule
> necessary if we have full @property support? I think this would still
> allow too many false positives.

(As a note, this is the current behavior.)

The way I see it is this is a natural consequence of optional parens. The name of a function without a "&" prepended or a "()" after it will invoke the function, and that's that.

> One important aspect that this proposal doesn't cover yet is whether we
> want to allow "semantic rewriting" for properties:
> ----
> Struct a;
> a.property++; //would this be legal?
> ----

It's dangerous to get too clever about that. Anyhow, such rewrites are possible:

++a.p ----> { auto v = a.p; ++v; a.p = v; return v; }()
a.p++ ----> { auto v = a.p; ++a.p; return v; }()

and so on.

> for other corner cases this list is a good start:
> http://wiki.dlang.org/Property_Discussion_Wrap-up#Implementation_concerns
>
> * Can we get a reference to the property? What does
>    &x.property mean?

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.

> * How can we get the getter / setter functions? Do we need to get those?

Per (2) above there is no need for special provisions.

> * What is the type of the property? Return type, setter function type
>    or getter function type? How to get the other types?

typeof(r.front) is the return type of the property, typeof(&(r.front)) is the type of a pointer to the return type of the property where applicable, and typeof(&r.front) is the (possibly ambiguous) address of the method. (To disambiguate one would use the appropriate receiver type.)

> * What does x.property++ do?
>    ([http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Property#Semanticrewritingofproperties
>    Semantic rewriting])

Added to http://wiki.dlang.org/DIP23.

> * Is returning ref values from the getter OK?

I see no reason to disallow it at the language level.

> * Is taking ref values in the setter OK?

How do you mean that?

> * Should all properties be nothrow? pure? getter const?
> ** Probably better as a rule for style guide.

No restriction at language level.

> * Are UFCS properties possible? How do they work exactly?
> * How do you disambiguate property functions when they're free
>    functions which conflict?

I think it would be best to simply disallow parameterless module-level properties.

// at top level
@property int foo(); // error
@property int goo(int); // fine, assume a getter for int

> ** Normal UFCS functions can be force
>    called by using their fully qualified name. That's not possible for
>    properties if function call syntax is disallowed?

Correct. Writing @property buys the writer into a constrained universe.

> * How many parameters are allowed for property functions?

One or two at top level, zero or one at member level.

> ** Are default parameters allowed?
> ** Especially consider the example about __FILE__ and __LINE__

I'd say no. Just keep it simple and focused on the goal.

> * Are templated properties allowed?
> ** The access syntax for properties doesn't allow providing types

No. Templated member variables are not allowed either.


Andrei

On Sun, 03 Feb 2013 10:35:29 -0500, TommiT <tommitissari@hotmail.com> wrote:

> On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu wrote:
>> Walter and I have had a discussion on how to finalize properties.
>>
>> http://wiki.dlang.org/DIP23
>> [..]
>
> What happens here?
>
> struct S
> {
>      int _n;
>
>      @property ref int prop()
>      {
>          return _n;
>      }
> }
>
> @property void prop(ref S s, int n)
> {
>      s._n = 42;
> }
>
> void main()
> {
>      S s;
>      s.prop = 10;
> }

I would expect it to call S.prop, not the global prop.  If not, that should be a bug (Kenji, you should add this case to the tests if not already there)

With UFCS, you cannot override type-specified methods and properties.

-Steve

On 2013-02-03 16:35, TommiT wrote:
> What happens here?
>
> struct S
> {
>      int _n;
>
>      @property ref int prop()
>      {
>          return _n;
>      }
> }
>
> @property void prop(ref S s, int n)
> {
>      s._n = 42;
> }
>
> void main()
> {
>      S s;
>      s.prop = 10;
> }

This is an interesting problem.
1) I think setters should outrank getters when there's an assignment.
2) Also actual methods outrank UFCS free functions with same arguments.
It's a question which rule has higher precedence.
I think no.2 does and then _n becomes 10.

On Sunday, 3 February 2013 at 16:03:50 UTC, Steven Schveighoffer wrote:
> On Sun, 03 Feb 2013 10:31:31 -0500, deadalnix <deadalnix@gmail.com> wrote:
>>
>> If you want a function, then just don't annotate with @property. The whole point of property is that it doesn't behave like a function.
>
> That is not the point of properties.  The point of properties is to have hooks for field setting and getting.  They necessarily behave like functions.
>
> -Steve

That is not the point of properties. The point of setter and getter methods is to have hooks for field setting and getting. The point or properties is to have clearer semantics than what regular setter and getter methods would have.

Am Sun, 03 Feb 2013 17:01:59 +0100
schrieb "TommiT" <tommitissari@hotmail.com>:

> On Sunday, 3 February 2013 at 15:48:00 UTC, Johannes Pfau wrote:
> >> -----------
> >> In order to use the assignment operator "=" property-style, the @property annotation MUST be used.
> >> -----------
> >
> > There's a example on the page though which contradicts this:
> >
> > static int x;
> > ref int fun1() { return x; }
> > fun1 = 42;
> 
> That example has nothing to do with properties. It's just:
> 
> static int x;
> ref int fun1() { return x; }
> fun1() = 42;
> 
> ...except that the empty parens were omitted (which is allowed there).

OK, but then 'In order to use the assignment operator "=" property-style, the @property annotation MUST be used.' is wrong or a least misleading. IMHO "fun1 = 42;" is using "=" 'property style'. But if you think of it as a parentheses-less call that indeed makes sense.

2013/2/4 Andrei Alexandrescu <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