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 
needed.

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


More information about the Digitalmars-d mailing list