Worst ideas/features in programming languages?

Timon Gehr timon.gehr at gmx.ch
Tue Oct 12 21:38:48 UTC 2021

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 
- 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
- mixin identifiers
- __local, static break and continue 
- template literals
- 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
- 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
- strong variable updates (probably not happening)
- non-lexical variable lifetimes (probably not happening)
- parametric polymorphism, in particular for type qualifiers (probably 
not happening)
- some amount of dependent types (dreaming now)

More information about the Digitalmars-d mailing list