Worst ideas/features in programming languages?

[Dr Machine Code]

On Tuesday, 12 October 2021 at 21:38:48 UTC, Timon Gehr wrote:
> On 10/11/21 5:59 PM, Atila Neves wrote:
>> ...
>
> This is likely to be incomplete or overly abstract, but here's 
> my approximate take:
>
>> * Worst features implemented in a non-toy language
>
> - unsound type system
> - undefined behavior for categories of errors other than memory 
> corruption
> - inappropriately nondeterministic semantics
> - mutable aliasing by default (mutability is fine, aliasing is 
> the issue)
> - pointer arithmetic without appropriate type system support
> - imprecise type system (>40 years behind state of the art)
> - non-orthogonal language definition
> - null pointers without appropriate type system support
> - Turing-complete constructors
>
>> * Worst features (in your opinion) in D
>
> - undefined behavior for categories of errors other than memory 
> corruption, e.g. 'assert'
> - @safe `void` initialization
> - @safe extern(C) function prototypes
> - inout
> - nondeterministic floating-point semantics
> - forward reference errors/ambiguities (arising from 
> underspecification of compile-time introspection)
> - .init
> - separation of templates and CTFE
> - null pointers
> - Turing-complete constructors
> - Object
> - interaction of type qualifiers with reference types
> - underspecification of type/function qualifiers
> - template syntax is inconsistent between declaration and call 
> site
> - alias this (it uses lookup rules different from import)
> - slicing and indexing of sequences is magic, there is no way 
> to slice a library tuple without decaying into an 
> auto-expanding sequence
>
>> * Features you'd like to see in D
>
> - built-in tuples/products with standard syntax
> - built-in tagged unions/sums, nullable, algebraic data types
> - pattern matching
> - real support for linear/affine typing
> - named parameters with support for perfect forwarding and 
> compile-time introspection
> - built-in duck-typed record types playing nice with named 
> parameters
> - type classes / some standard way to add UFCS methods to a 
> type from another module that are then visible in an 
> instantiated template from a third module
> - uniform syntax for function definition, in particular `int 
> add(int a,int b)=>a+b;` (-preview=shortenedMethods)
> - `let Statement in Expression` expression
> - `Expression where Statement` expression

could you give example what those would be like?

> - mixin identifiers
example?
> - __local, static break and continue
what would __local do?

> (https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1010.md)
> - template literals
example?
> - static opIndex/opSlice
> - AST introspection
> - consistent treatment of operators for built-in types, e.g. 
> 1.opBinary!"+"(2) should work.
> - operator overloading should combine orthogonally with UFCS
> - better support for subtyping (expose the concept to 
> user-defined types, e.g., Range!(const(T)) could be a subtype 
> of const(Range!T)) and any other features required to support a 
> good container library
> - async/await (or similar)
> - yield (or similar)
> - range literals
what's that?
> - more lightweight coroutines
> - ProtoObject
> - special treatment of qualified types, in particular qualified 
> reference types (e.g. `immutable` classes should allow 
> conversion of references from `immutable` to mutable)
> - non-deterministic semantics, with as little undefined 
> behavior as possible, in particular for type/function qualifiers
> - compile-time fixed-point support (e.g., with struct S(T){ T* 
> next; }, fix!S gives a singly linked list).
> - flow-sensitive typing
what's that?
> - strong variable updates (probably not happening)
what's that?
> - non-lexical variable lifetimes (probably not happening)
> - parametric polymorphism, in particular for type qualifiers 
> (probably not happening)
> - some amount of dependent types (dreaming now)

you got very nice features, are you making DIPs for those?