DIP26: properties defined

[Jonathan M Davis]

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