Worst ideas/features in programming languages?

Timon Gehr timon.gehr at gmx.ch
Sun Jan 9 09:51:06 UTC 2022

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.

More information about the Digitalmars-d mailing list