Ouch: return values as lvalue

[Andrei Alexandrescu (See Website For Email)]

Lionello Lunesu wrote:
> "Andrei Alexandrescu (See Website For Email)" 
> <SeeWebsiteForEmail at erdani.org> wrote in message 
> news:45BF7C8B.3080506 at erdani.org...
>> Lionello Lunesu wrote:
>>> Consider this home-made const:
>>>
>>> struct Task {
>>>   char[] ID;
>>> }
>>> private Task _CurrentTask; //mutable
>>> public Task CurrentTask() { return _CurrentTask; } //const
>>>
>>> public void StopTask() {
>>>   CurrentTask.ID = null;
>>> }
>>>
>>> Notice the bug? That last line should read "_CurrentTask.ID = null;"
>>>
>>> Isn't there something the compiler can do to help me catch these bugs?
>> const will take care of it. The code above fetches a member of an rvalue, 
>> which is an lvalue.
> 
> Yeah, I know, but it's odd: it's setting a member in a struct that's about 
> to be deleted. It's like writing "{ int id=4; }". Wouldn't it be possible 
> for the compiler to warn about "code without side-effect" or something?

It's a long discussion. I agree that non-templated code without effect 
should issue a compile-time error (not warning) _____as long as under no 
change of type definitions etc., the code could make sense_____.

Consider:

struct RealLock { ... }
struct DummyLock { ... }
alias DummyLock Lock;

{
   Lock lock;
   ...
}

DummyLock doesn't do anything. The idea is that the user would replace 
the alias with RealLock in a multithreaded application.

The compiler shouldn't issue an error, even though the code appears to 
do nothing interesting.


Andrei