While we're lynching features, how bout' them omittable parens?

Ary Borenszweig ary at esperanto.org.ar
Tue May 19 14:54:46 PDT 2009


Jérôme M. Berger escribió:
> Robert Fraser wrote:
>> Chad J wrote:
>>> Nevermind properties.  Any chance we can forbid the omittable
>>> parentheses, at least in the lhs of an assignment expression?
>>>
>>> In the more general case, any value type that gets modified but never
>>> read or copied elsewhere is probably either dead code, a bug, or a
>>> benchmark.  The latter is easy to fix by adding the necessary read/copy
>>> (return the value, pass it to a global or function, etc).  It'd be great
>>> if this kind of thing were a compile time error.
>>>
>>> Code like this shouldn't compile:
>>>
>>> struct S { int a = 0; }
>>> S foo() { S s; return s; }
>>>
>>> void main()
>>> {
>>>     foo.a++;
>>> }
>>
>> Whatever solution to this is chosen *please* don't make "get", "set", 
>> "value" or "prop" into keywords! "in", "out", "body" and "shared" used 
>> to be common features of my coding style; I'm not sure it can take 
>> another blow. As Andrei mentioned somewhere, keywords aren't cheap.
> 
>     How about:
> 
> int x { setter, getter };
> int setter();
> void getter (int);
> 
>     Where either one of the accessors may be null (or omitted):
> 
> int readonly { null, getter };
> int writeonly { setter, null };
> 
>  - It doesn't need a new keyword;
>  - It can't be confused with function declarations because those need 
> parentheses anyway;
>  - Ideally, the compiler would infer the type of the accessor from its 
> prototype (i.e if it doesn't take any arguments and returns T, then it's 
> the getter, if it takes a T and returns void then it's the setter, 
> otherwise it's an error).
> 
>     Of course, this would *not* allocate any space in the class/struct.
> 
>         Jerome

Please don't start a subthread about how to implement properties. I 
think this is the third or fourth time this is discussed here. :)

The problem isn't the syntax; the problem is that none of the people who 
make D see something useful in distinguishing properties from regular 
function calls without parameters.



More information about the Digitalmars-d mailing list