Why is std.algorithm so complicated to use?

[Timon Gehr]

On 07/10/2012 01:34 AM, Jonathan M Davis wrote:
> On Tuesday, July 10, 2012 01:20:21 Timon Gehr wrote:
>>> Now, with the current version of github, it unfortunately
>>> seems to spit out a bunch of duplicate messages for the same error/warning
>>> with templates in a number of cases, and _that_ should be fixed, but the
>>> warnings themselves are generally solid and indicators of a real problem.
>>>
>>> And as I've expressed in the past, I think that -property is very much
>>> doing the right thing and that not strictly enforcing properties is
>>> horrible,
>> Language design shouldn't be based on statements like "I think it is
>> horrible". There is nothing objective in it.
>
> Without -property, it's lax. The rules aren't enforced.

Yes they are. It is just another set of rules.

> It allows you to use a function as if it were a property when it's not.

No, it allows you to call a function by calling it's name. Walter
presumably got this from Eiffel, where it is called 'uniform access
principle'.

> Language rules should be
> strictly enforced not be left up to the programmer whether they want to bother
> following them or not.  That just leads to confusion and bugs.

That is the realm of unsafe casts. We are just discussing syntax here.
Less brackets are better, because it is easier to match them. Fact.

> If the API
> states that it's @property, so it should be used as a property. If the API
> says that it should be used as a function, then it should be used as a
> function.

function;

is a perfectly good function call. It is used as a function.

It is none of the API's business to claim that it must be called like 
function(), just because that brings in good memories of C. There are
enough languages that got rid of the obligatory '()'.

> You wouldn't use () on a variable would you (aside from defining
> opCall)?

delegates and function pointers come to mind. But that is besides the point.

> I should think not, and I don't think that () should be left out on a
> function any more than they should be used on a variable. It's sloppy and
> confusing.

We are going to disagree on that. Note that '()' can always be included
as a visual clue if it makes sense. There are however cases where it
does not.

>
> Regardless, TDPL calls for strict property enforcement, so that's where we're
> headed.
>

I have heard that rumour, but TDPL wisely specifies the behaviour of
the @property attribute as follows:

'In particular "property" is recognized by the the compiler
and signals the fact that the function bearing such an attribute must be 
called without the trailing ().'

That is exactly the behaviour I described.

Note that this sentence includes the notion of _calling a function_
without the trailing () and it even seems to express that the trailing
() is usually optional.

So TDPL actually describes a subset of what I have in mind. (it seems
to leave out the function = argument case completely.) We should
therefore change where we are headed.