Which language constructs could be done as a library if we accept some breaking changes?

[Ola Fosheim Grøstad]

On Monday, 29 November 2021 at 13:56:08 UTC, Petar Kirov 
[ZombineDev] wrote:
> 2. Type qualifiers. I really like D's type qualifiers, 
> including `shared`, but after using TypeScript at work for the 
> past 2-3 years, I feel their approach is more flexible - simply 
> offer head-only type qualifiers and build transitive ones on

Yes, it is a powerful concept, but TypeScript is "reinterpreting" 
the underlying types. If done in D it might be the same as 
refining types with constraints.

A long time ago I suggested using reqular expressions for 
expressing constness, which perhaps is what TypeScript is doing. 
Just with a verbose syntax.

It could be done in a more concise fashion by borrowing ideas 
from query languages for tree-datastructures, such as XQuery or 
CSS selectors.

Using the more verbose syntax of TypeScript only makes sense if 
you also do your point 3:

> 3. Replace `interface` types and ad hoc Design-by-Introspection 
> patterns like `isInputRange`, `hasMember!(S1, "member")` with 
> TypeScript's object types: 
> https://www.typescriptlang.org/docs/handbook/2/objects.html 
> which offer a very powerful, yet elegant and concise way of 
> describing object shapes.

Concepts/traits in C++ and Rust are making the lack of this 
feature more apparent, I guess.

> 4. Replace ad hoc DIP1000 parameter storage class design with 
> affine types. I haven't given it much thought, but ideally we 
> should be able to write an Affine type constructor in library 
> code and simply use it like as any other type constructor (e.g. 
> tuple, sum type, etc.)

By "affine types" in this context, do you mean "use once or 
never" types?

> 5. Introduce some concept of compile-time dependency resolution 
> / context abstraction (see 
> https://docs.scala-lang.org/scala3/reference/contextual.html) 
> so that things like the current allocator, scheduler, 
> request/response context, etc., can be  implicitly provided to 
> improve the ergonomics of such APIs. For example, one could 
> specify that in one scope the current implementation of 
> associative arrays is a GC-managed hashmap, while in other a 
> unique_ptr to red-black tree value container, like `std::map`, 
> all while using the same `K[V] x = [key1: value1]` syntax.

So you would make all functions "templated"? Or, how else would 
this work?