On Saturday, February 09, 2013 00:53:30 Robert wrote:
> Ok. Here finally it is:
> 
> http://wiki.dlang.org/DIP26

I completely disagree with disallowing UFCS properties. Not only is it outright required for arrays, but it's currently possible to turn anything into a range (even types over which you have no control) simply by defining the functions (including property functions) for it externally. And you could do the same with most any API required by a template. If UFCS properties were disallowed, then that would become impossible for any API which included properties. That's unnecessarily restrictive.

- Jonathan M Davis

On Fri, Feb 08, 2013 at 10:04:11PM -0800, Jonathan M Davis wrote:
> On Saturday, February 09, 2013 00:53:30 Robert wrote:
> > Ok. Here finally it is:
> > 
> > http://wiki.dlang.org/DIP26
> 
> I completely disagree with disallowing UFCS properties. Not only is it outright required for arrays, but it's currently possible to turn anything into a range (even types over which you have no control) simply by defining the functions (including property functions) for it externally. And you could do the same with most any API required by a template. If UFCS properties were disallowed, then that would become impossible for any API which included properties. That's unnecessarily restrictive.
[...]

Yeah, I disagree with disallowing UFCS properties too. That just cripples it so much that a lot of existing @property use cases are invalidated. It feels like throwing out the baby with the bathwater, instead of solving the actual problem.


T

-- 
It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton

I am claiming that if we restrict ourselves to the property concept explained in the DIP, then the range API would no longer depend on front being a property, it can also be a function returning ref, which is perfectly legal for UFCS.

I am further claiming that properties via get/set methods don't actually make sense outside of the entity that define them, I am glad if you could give an actual example that would prove me wrong.

And because properties are treated (apart from allowing = to call the set method) exactly like normal functions, you should note no difference.

It feels to me, that most problems arise due to the fact that we try to make properties like fields (forbidding parentheses), which make them essentially incompatible to functions, resulting in making all sorts of things properties, which actually aren't, just so that no template breaks.

Maybe I should make this more clear in the DIP.
On Fri, 2013-02-08 at 22:04 -0800, Jonathan M Davis wrote:
> I completely disagree with disallowing UFCS properties. Not only is
> it
> outright required for arrays, but it's currently possible to turn
> anything
> into a range (even types over which you have no control) simply by
> defining the
> functions (including property functions) for it externally. And you
> could do
> the same with most any API required by a template. If UFCS properties
> were
> disallowed, then that would become impossible for any API which
> included
> properties. That's unnecessarily restrictive.

On Saturday, February 09, 2013 10:45:13 Robert wrote:
> I am claiming that if we restrict ourselves to the property concept explained in the DIP, then the range API would no longer depend on front being a property, it can also be a function returning ref, which is perfectly legal for UFCS.
> 
> I am further claiming that properties via get/set methods don't actually make sense outside of the entity that define them, I am glad if you could give an actual example that would prove me wrong.
> 
> And because properties are treated (apart from allowing = to call the set method) exactly like normal functions, you should note no difference.
> 
> It feels to me, that most problems arise due to the fact that we try to make properties like fields (forbidding parentheses), which make them essentially incompatible to functions, resulting in making all sorts of things properties, which actually aren't, just so that no template breaks.
> 
> Maybe I should make this more clear in the DIP.

I just went over this with Kenji in his thread "Partial modification of DIP23 to allow module level property." You _must_ be able to rely on front being a property.

With any API that templates use, the exact syntax of the functions or properties used must be defined. Otherwise, you're going to be screwed by things like a templated function using parens to access a property working in some cases and not in others (because some types defined it as a function whereas others defined it as a property). Even worse, it _completely_ breaks properties which return delegates. front() _must_ make the call on the return value of front and not just call front. If front can sometimes be a function or sometimes be a property, then the code will function drastically differently depending on whether one or two sets of parens were used.

It's bad enough that parenless function calls are legal, but if you let a part of your API be either a property or a function, you're asking for it. Code _will_ break at some point because of that inconsistency. Generic just code can't afford it. And when we're talking about something in the standard library, it's that much more critical.

- Jonathan M Davis

On 2013-02-09 11:31, Jonathan M Davis wrote:
> I just went over this with Kenji in his thread "Partial modification of DIP23
> to allow module level property." You _must_ be able to rely on front being a
> property.

front getter MUST be a property... as in RFC2119's MUST??
So all those 75 std @property ref T foo() are also here to stay for good?
Bah, banning ref fixed some things, but now it's back to square one again.
Maybe it's time to drop the property subject and move on? :)

On Saturday, February 09, 2013 12:31:14 FG wrote:
> On 2013-02-09 11:31, Jonathan M Davis wrote:
> > I just went over this with Kenji in his thread "Partial modification of DIP23 to allow module level property." You _must_ be able to rely on front being a property.
> 
> front getter MUST be a property... as in RFC2119's MUST??
> So all those 75 std @property ref T foo() are also here to stay for good?
> Bah, banning ref fixed some things, but now it's back to square one again.
> Maybe it's time to drop the property subject and move on? :)

You must be able to rely on front always being used without parens, and you must be able to rely on front() doing a call on the return value rather than simply calling front. Otherwise, you're going to have problems with code erroneously using parens to call front and breaking when used with anything that actually defines it as a property, and you'll break anything involving delegates or other callables. Returning ref is irrelevant, especially if we get full property rewrites (e.g. front += 7 and the like works with property functions without ref). What matters is that the syntax is consistent and that the semantics of using parens on front are consistent. Generic code needs to work with anything with the right API, and making front a function will cause problems with that.

- Jonathan M Davis

The DIP actually solves this.
On Sat, 2013-02-09 at 02:31 -0800, Jonathan M Davis wrote:
> I just went over this with Kenji in his thread "Partial modification
> of DIP23
> to allow module level property." You _must_ be able to rely on front
> being a
> property.
> 
> With any API that templates use, the exact syntax of the functions or
> properties used must be defined. Otherwise, you're going to be screwed
> by
> things like a templated function using parens to access a property
> working in
> some cases and not in others (because some types defined it as a
> function
> whereas others defined it as a property). Even worse, it _completely_
> breaks
> properties which return delegates. front() _must_ make the call on the
> return
> value of front and not just call front. If front can sometimes be a
> function
> or sometimes be a property, then the code will function drastically
> differently
> depending on whether one or two sets of parens were used.
> 
> It's bad enough that parenless function calls are legal, but if you
> let a part
> of your API be either a property or a function, you're asking for it.
> Code
> _will_ break at some point because of that inconsistency. Generic just
> code
> can't afford it. And when we're talking about something in the
> standard
> library, it's that much more critical.
> 
> - Jonathan M Davis

On 2/9/13 5:31 AM, Jonathan M Davis wrote:
> With any API that templates use, the exact syntax of the functions or
> properties used must be defined. Otherwise, you're going to be screwed by
> things like a templated function using parens to access a property working in
> some cases and not in others (because some types defined it as a function
> whereas others defined it as a property). Even worse, it _completely_ breaks
> properties which return delegates. front() _must_ make the call on the return
> value of front and not just call front. If front can sometimes be a function
> or sometimes be a property, then the code will function drastically differently
> depending on whether one or two sets of parens were used.
>
> It's bad enough that parenless function calls are legal, but if you let a part
> of your API be either a property or a function, you're asking for it. Code
> _will_ break at some point because of that inconsistency. Generic just code
> can't afford it. And when we're talking about something in the standard
> library, it's that much more critical.

Evidence has it the other way around. We've defined plenty of fine std ranges and algorithms before @property adorned front everywhere (something I'm looking forward to get rid of).

Andrei

On 2/9/13 6:31 AM, FG wrote:
> On 2013-02-09 11:31, Jonathan M Davis wrote:
>> I just went over this with Kenji in his thread "Partial modification
>> of DIP23
>> to allow module level property." You _must_ be able to rely on front
>> being a
>> property.
>
> front getter MUST be a property... as in RFC2119's MUST??
> So all those 75 std @property ref T foo() are also here to stay for good?

I hope not.

Andrei

On Saturday, 9 February 2013 at 09:45:25 UTC, Robert wrote:
> I am claiming that if we restrict ourselves to the property concept
> explained in the DIP, then the range API would no longer depend on front
> being a property, it can also be a function returning ref, which is
> perfectly legal for UFCS.
>
> I am further claiming that properties via get/set methods don't actually
> make sense outside of the entity that define them, I am glad if you
> could give an actual example that would prove me wrong.
>
> And because properties are treated (apart from allowing = to call the
> set method) exactly like normal functions, you should note no
> difference.
>
> It feels to me, that most problems arise due to the fact that we try to
> make properties like fields (forbidding parentheses), which make them
> essentially incompatible to functions, resulting in making all sorts of
> things properties, which actually aren't, just so that no template
> breaks.
>

That was painful to read. Can you please answer AFTER what you quote ? Also, you don't address most of the point Jonathan raises, and that should probably be a sign that you are not mastering the topic enough.