new DIP5: Properties 2

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> On Fri, 31 Jul 2009 16:53:12 -0400, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
> 
>> Steven Schveighoffer wrote:
>>> But in the case of properties only allowed without parens, functions 
>>> require parens, you are defining a rule for the compiler.  Think of 
>>> the parentheses as an extension of the function name, like punctuation.
>>
>> But you say no parens means query, parens means action. This is sheer 
>> unchecked convention.
> 
> But we already have sheer unchecked convention!  I could make a function 
> called sort that reverses an array.

Of course we do. My point is that there's no need to add gratuitous 
mechanisms fostering conventions that go unchecked.

> I don't get why it makes any 
> difference to you that the meaning of parentheses and no parentheses is 
> used by the author of the function.  How is this bad or somehow worse 
> than what we have now?  If you don't trust the author's functions do 
> what they are named for, don't use his functions and properties.

Well you can trivialize all you want but the matters are different. It's 
one thing to have good names, good designs, trusted code etc. and a 
whole different thing to define a feature of which entire existence only 
serves only an unchecked convention.

> Since C was invented, we have had the convention that () means function, 
> lack of () means property.  You are acting like the last 37 years of 
> programming languages never existed, and this is some "new radical" 
> convention.  D is of C lineage, so using long standing C conventions 
> should not confuse people.

Well C never had properties that executed code, so following the lineage 
is a moot point. C also didn't have a variety of other things, such as 
member functions. But we do have now. All I want is to not add undue 
burden. To me, it would be a mistake if D defined a special syntax for 
defining properties as if they were some big deal, to then not check in 
any way that they behave any different than regular functions.

>> Maybe less confusion, definitely more burden.
> 
> The burden is on the author to come up with meaningful function names 
> already.  With real properties, at least that task is easier because you 
> don't need to add extra context to ensure a word is treated as a verb or 
> a noun (e.g. 'isEmpty' in order to make sure someone doesn't mistake 
> 'empty' for an action).  The compiler enforces the requirement of 
> property syntax vs. function syntax, so no burden there.

No, you add burden by posing the question, do I want people to call with 
parens or without? There's always going to be a gray area and there's 
always going to be surprising APIs (see e.g. Daniel Keep's point about 
range APIs that must actually do stuff in r.empty). With a uniform 
convention, all of these issues vanish.

To clarify: if there was any extra checking by the compiler, any 
guarantee that the feature would provide at all, I'd be glad to pay the 
price of thinking more when putting together a design. But you want to 
define a language feature that allows people to require "()" or not as 
they please, and that's all. It's a frivolous detail to be spending time 
on when designing an API. I simply don't believe that's good language 
design.


Andrei