Worst ideas/features in programming languages?

Walter Bright newshound2 at digitalmars.com
Sat Jan 8 01:01:56 UTC 2022

On 1/3/2022 8:30 PM, Timon Gehr wrote:
> On 29.12.21 06:09, Walter Bright wrote:
>> @live currently does that for pointers, but not for non-pointers.
> It removes the variable from the scope? (And anyway, @live is a function 
> annotation, which makes little sense.)

@live applies to all the contents of the function.

`scope` is ignored for non-pointer variables, whether they are @live or not.

>> What's the use case for it?
>> ...
> This is just how moving things works. If you move it, it's no longer where it 
> was. If the variable disappears, we don't have to bother with putting `x` into 
> some safe default state. Some types can't even naturally support a safe default 
> state. The simplest example is indeed a `struct` implementing a unique non-null 
> pointer managing its own memory. (By whatever means you want, it does not even 
> have to have any pointer members to implement such semantics.)
>>> int y=move(y); // ok
>>> ```
>> I see what you mean, but since D disallows:
>>      int x; { int x; }
>> which prevents a number of bugs, so I can't see allowing that.
> I don't see how that's related. It's two variables `y` whose lifetimes do not 
> overlap. It's more like this:
> {int x; } { int x; }
> Which D allows.

You are pedantically correct, but it's one of those things that would be 
disallowed because it *looks* like a bug. There's no ambiguity to

     int x; { int x; }

either, it just *looks* like a bug, and a good chunk of the time it is not 
intended by the user and is a bug. I haven't seen a case yet where such code is 

I don't see a necessity to allow the y redeclaration.

More information about the Digitalmars-d mailing list