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
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
- mixin identifiers
- __local, static break and continue
(https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1010.md)
- 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