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