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

BCS none at anon.com
Mon May 18 19:22:37 PDT 2009


Hello dsimcha,

> == Quote from Chad J (chadjoan at __spam.is.bad__gmail.com)'s article
> 
>> Lionello Lunesu wrote:
>> 
>>> "Chad J" <chadjoan at __spam.is.bad__gmail.com> wrote in message
>>> news:gut0f2$jc0$1 at digitalmars.com...
>>> 
>>>> 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++;
>>>> }
>>> This is not because of the omittable parens. Even with added parens
>>> that code should not compile!
>>> 
>>> L.
>>> 
>> Agreed!
>> 
> Yeah, file a Bugzilla.  Shouldn't ++, +=, etc. only work on lvalues?
> 

Strictly speaking foo.a is an lvalue. Maybe value return types shouldn't 
be? I think that might be the best keyhole fix.





More information about the Digitalmars-d mailing list