On 2013-02-09 15:30:13 +0000, "deadalnix" <deadalnix@gmail.com> said:

> On Saturday, 9 February 2013 at 12:44:35 UTC, Michel Fortin wrote:
>> I believe both module-level properties and UFCS properties to be desirable. So is the idea put forward in DIP26 that reduces boilerplate code. The question is how do we put all that together.
> 
> Well design is a balance between conflicting goals. Allowing both cause an extra complication. So the win have to actually be carefully considered.

Only because of the constrains people seem to have wrapped themselves into. If you want to use @property to designate a property (which doesn't distinguish setter and getter) then you run in the problem of not being able to distinguish UFCS getter from non-UFCS setter. So of course if you impose yourself the constrain of having something ambiguous you need some other rule to disambiguate.


> @properties as UFCS are almost mandatory. They are used everywhere, especially for arrays.

Setters or getters? UFCS "getters" are not a problem with this DIP. Quoting my other post:

> So whether a getter is a property or not does not change anything at the call site, meaning that UFCS getters (or any getter with no associated setter for that matter) don't need to be properties. What remains is that you can't write UFCS *setters*. But UFCS setters are definitely less common, and if that's really important I guess it could be solved though separate means.
> 
> So in short, this proposal is that @property does only two things when applied to a function: it enables the setter syntax and it changes the overload rules.



-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

On 2013-02-09 15:22:28 +0000, Jacob Carlborg <doob@me.com> said:

> I completely agree, I really like it. Do we want to be able to use attributes like "final", and perhaps others, when declaring a property field:
> 
> @property final int a;
> 
> The lowered functions would have the "final" attribute attached to them self.

That'd make a lot of sense.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

I already thought about this too, good enough that D choose not to use final for const variables like Java does.

On Sat, 2013-02-09 at 12:54 -0500, Michel Fortin wrote:
> On 2013-02-09 15:22:28 +0000, Jacob Carlborg <doob@me.com> said:
> 
> > I completely agree, I really like it. Do we want to be able to use attributes like "final", and perhaps others, when declaring a property field:
> > 
> > @property final int a;
> > 
> > The lowered functions would have the "final" attribute attached to them self.
> 
> That'd make a lot of sense.
> 

On Fri, 08 Feb 2013 18:53:30 -0500, Robert <jfanatiker@gmx.at> wrote:

> Ok. Here finally it is:
>
> http://wiki.dlang.org/DIP26

Wow. So you simply want to go back to D1-style properties.

It would have been simpler to just specify that we define a property like this:

// this is a property
int foo() {...}

-Steve

> // this is a property
> int foo() {...}
It is, if you consider properties to be functions that can be called without parentheses. Which is quite a lame definition of property if you ask me.

But yeah my proposal makes properties to be considered functions, just with some guarantees regarding encapsulation and the special syntax that

prop=a;

means: prop(a);

Actually Michel Fortin summarizes the DIP quite to the point:

> So in short, this proposal is that @property does only two things
when
> applied to a function: it enables the setter syntax and it changes
the
> overload rules.
> 

In addition it restricts the setter syntax (prop=a) to be interpreted in
a non UFCS way, meaning there will be no setter methods with two
parameters. (Not accounting for the implicit this parameter)

On Fri, 2013-02-08 at 22:00 -0800, Jonathan M Davis wrote:
> It would be simple enough to make it so that the compiler used auto
> ref in the
> lowered version and just make the variable itself int, though the DIP
> obviously doesn't say that.

That would be impossible for virtual functions in a class. What the compiler could do, is simply provide both. This has to be thought through, what is important is that it is very clear what the compiler produces.

As properties are meant to be assigned (which implies a copy at some point), you usually try to keep them small anyway or making them a class so that you only have to assign a reference. So I think it is not a bad choice to have the compiler simply generate the most simple trivial form, taking the argument by value. If you really want something different in some special application, you may still provide the functions on your own.

Having said that, I really don't mind having the compiler produce both, if people think this is a good idea.