Worst ideas/features in programming languages?

[Timon Gehr]

On 1/8/22 02:01, Walter Bright wrote:
> 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.
> ...

And none of the calling context. As I said, makes little sense.

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

The language can't know what's designed to act like a pointer.

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

Perhaps that's what it looks like to you, but to other people it just 
looks like the typestate pattern, for example.

> 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 fully agree that variable hiding is error prone, but that's just not 
what's going on here.

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

_Redeclaring_ an _existing_ variable is of course disallowed. Declaring 
a variable of the same name as one that's consumed in its initializer is 
rather common (e.g. typestate pattern). And it is convenient and not 
error prone at all.