Revised RFC on range design for D2

[Bruno Medeiros]

Andrei Alexandrescu wrote:
> Bruno Medeiros wrote:
>> Andrei Alexandrescu wrote:
>>> Bruno Medeiros wrote:
>>>> Sergey's argument (which is much more objective than subjective) is 
>>>> not strictly against omitting parenthesis, but rather against 
>>>> ambiguity (the dual possible ways to call zero-args functions), 
>>>> which as has been shown, creates various possibilities for bugs when 
>>>> you mix functions that return delegates. This ambiguity problem 
>>>> would also be resolved if omitting parenthesis would be *the only 
>>>> way* of calling functions with zero-args.
>>>
>>> Yah, he made great points. There are ambiguities. The 
>>> counter-argument is that that would make the syntax of calling 
>>> functions with no arguments inconsistent with the syntax of calling 
>>> function with arguments. The "()" is a degenerate case of "(a, b, 
>>> c)". So it's hard to keep everybody happy.
>>>
>>
>> Yes, if we solved the ambiguity problem that way, we would make a lot 
>> of people unhappy (myself included). But if we solved the problem the 
>> *other way* (forbidding omittable parenthesis for normal zero-args 
>> function), it would make, that I know of, only one person unhappy (you).
> 
> So there is a cabal. I knew it! :o)
> 

If there is a cabal, it's a pretty lame one... Walter's Inner Circle are 
the ones with all the power! :o)

> I'm not that sure about "lot" and "one", and numbers-based arguments 
> aren't that strong to begin with. Language design is complex and full of 
> tradeoffs. In each decision there are consequences. If we require "()" 
> then we must come with a separate thing for properties - an addition to 
> the language. Then many people (maybe even including some the "lot" of 
> people you mentioned) will cry foul: "where's my simple language?" etc. 
> Maybe some people will say, hey, you were already there with the 
> omittable "()" and the "=" thing, why didn't you just make the latter 
> less trigger happy and we'd be home free?
> 

Yes, we would need an alternate mechanism for properties - an addition 
to the language. And it's quite true that it's likely there would be 
disagreement in the "lot of people" about that. But there is only one 
way to be sure, so we could at least try! Would you and Walter at least 
consider this, and see if we could find an alternative that satisfies a 
fair number of people? Try without compromise.

In fact, I'm also not a fan of those complex property mechanisms, à lá 
C#. I think a fair candidate would be Bill Baxter's proposal, the 
'property' keyword:

   property int foo() { return _foo; };
   property void foo(int foo) { _foo = foo; };

The property keyword would make a function callable *only* as a property 
syntax (either as reading, 'bar = foo;', or as writing, 'foo = 42;'). A 
function signature which was not adequate for property access would be 
compile-time error.
This proposal fixes the ambiguities issues, and require *minimal 
changes* to the language, both in terms of syntax and semantics!


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D