On Saturday, February 09, 2013 09:48:23 Andrei Alexandrescu wrote:
> 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).

The problem of consistenty comes up once @property is enforced. Right now, it's just useless markings on a function. It affects -property, but all - property does is complain about normal functions being called without parens. It doesn't properly enforce @property. If @property is enforced, then as long as it exists, APIs used by templates will need to be consistent about it or you're going to run into to problems.

Getting rid of @property will mean allowing stupid stuff like

range.popFrontN = 5;

as well as making it impossible for () to be used to called a delegate or other callable returned by what should be a property as well as impossible for a variable to be used in the place of a parenless function call, as it could be called with parens. Without explicit properties, we have no control over what's used as a property.

I'd very much hate to see @property just because it was never really implemented and so some folks (like you and Walter) came to the conclusion that we had somehow proved that it didn't work or wasn't a good idea. It would have to actually be implemented for us to have any actual data on how well it works in D. Getting rid of it because it's not working doesn't make sense, because it's never been implemented in the first place.

- Jonathan M Davis

On 2/9/13 2:21 PM, Jonathan M Davis wrote:
> Getting rid of @property will mean allowing stupid stuff like
>
> range.popFrontN = 5;

No. This again conflates getters with the setter syntax.

Andrei

On Sat, 2013-02-09 at 16:17 +0100, deadalnix wrote:
> 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.

Funny enough, when I read your posts I get the feeling you did not even read the DIP. Enough insulting for now?

On Saturday, February 09, 2013 14:56:56 Andrei Alexandrescu wrote:
> On 2/9/13 2:21 PM, Jonathan M Davis wrote:
> > Getting rid of @property will mean allowing stupid stuff like
> > 
> > range.popFrontN = 5;
> 
> No. This again conflates getters with the setter syntax.

How? If you don't have explicit properties, then _any_ function which has the appropriate set of parameters can be used as a property function, and there are many functions (both free functions and member functions) which have that set of parameters but clearly aren't meant to be properties. popFrontN is just one of them. The only reason that this isn't a problem in DIP23 is the fact that it makes it so that the only way that you get the setter syntax is to use @property.

Sure, you could decide that @property only applied to setters  and let getters only be done via parenless functon calls, but you'd still need explicit properties for setters to avoid problems like range.popFrontN = 5;. And if you get rid of explicit getters, then you're still losing when it comes to stuff like delegates and the ability to swap out variables with property functions like you're supposed to be able to do with properties.

- Jonathan M Davis

> 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.

Why? Think about it, this thinking comes from the fact that it was considered to be a good idea that front could be anything including a field or even an enum. The question is why would we want to allow this in the first place. It is never used in the standard library, it breaks encapsulation and every field or enum can easily be turned into a trivial function.

Maybe you are still referring to an early version of the DIP where I put there a sentence, (with a bad feeling already) that properties must not be called with (). I fixed this very bad mistake very soon afterwards, maybe you want to have another look?