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