Worst ideas/features in programming languages?

[Timon Gehr]

On 11/5/21 6:02 PM, Atila Neves wrote:
> On Tuesday, 12 October 2021 at 21:38:48 UTC, Timon Gehr wrote:
>> On 10/11/21 5:59 PM, Atila Neves wrote:
>>> ...
>> ...

Sorry, just noticed I never answered this...

>> This is likely to be incomplete or overly abstract, but here's my 
>> approximate take:
>>
>>> * Worst features implemented in a non-toy language
>>
>> - Turing-complete constructors
> 
> Care to explain?
> ...

The goal of construction is to create an instance that usually should 
satisfy a certain invariant. (I don't necessarily mean invariant 
contracts, often invariants are left implicit.)

Therefore, to construct an instance, all that needs to happen is input 
validation and moving the constructor arguments into the fields of the 
instance.

Right now, constructors first get you some instance _that does not yet 
satisfy the invariant_ and basically allows you to do anything you want 
with it. That's quite a drag on type safety. (E.g., good luck adding 
non-null pointers.)

```d
struct S{
     immutable int x;
     this(int x){
         foo();
         this.x=1;
         foo();
     }
     void foo(){ writeln(x); }
}

```

There just should not be a way to obtain instances that violate (type 
system) invariants.

I think Walter agrees that the constructor design is not optimal, 
especially regarding exception safety.

>> - @safe `void` initialization
> 
> For what types? It doesn't compile for pointers, for instance, and I 
> don't see why void initialising an int would be unsafe.
> ...

The backends may treat accessing it as UB. I'd expect both ldc and gdc 
to think accessing a void-initialized value is UB.

The worst thing is @safe void initialization for user-defined types.

>> - @safe extern(C) function prototypes
> 
> Instead of @trusted, you mean?
> ...

Yes, at least with @trusted you can find it with grep. Slapping @safe on 
something should never be dangerous.

>> - .init
> 
> Because?
> ...

It's Hoare's billion dollar mistake, extended to all types. Having a 
default instance is often antithetical to strong invariants. At least it 
can be hidden I guess.

>> - separation of templates and CTFE
> 
> What would it look like if they weren't separated?
> ...

Stefan's type functions come close. (But I'd like to have dependent 
types as well.) E.g., manipulating arrays of types in CTFE functions.

>> - interaction of type qualifiers with reference types
> 
> I'd love to know what you mean by this.
> 
> 

The most obvious one is that there is no way to declare a tail-mutable 
class reference.

There's also this:

```d
import std.stdio;
class C{
     static x = [1,2,3];
     this(){ x[0]=2; }
     this()immutable{}
}

void main(){
     auto a=new immutable(C)();
     writeln(a.x); // [1,2,3]
     auto b=new C();
     writeln(a.x); // [2,2,3]
}
```