If you could make any changes to D, what would they look like?

[H. S. Teoh]

On Wed, Oct 20, 2021 at 09:47:54AM +0000, SealabJaster via Digitalmars-d wrote:
> Just for giggles, without pesky things like breaking changes; rational
> thinking, logical reasoning behind the changes, etc.
> 
> What interesting changes would you make to the language, and what
> could they possibly look like?

1) Kill current int promotion rules with fire.

2) Kill autodecoding with the same.

3) Kill the current class hierarchy, make ProtoObject -> Object.

4) The compiler would infer which function parameters need to be runtime
and which can be completely resolved at compile-time. You wouldn't need
to separate the two; it would be inferred for you.  Well, OK, in some
cases this is not possible, then you have to annotate it. But otherwise,
it should be automatic.  Template functions and "ordinary" functions
would be one and the same.  The compiler figures out for you which
parameters should be compile-time and which should be runtime.  Flipping
a switch would toggle between optimizing for performance (maximize
compile-time binding) vs size (minimize compile-time binding, genericize
parameters to accept polymorphic runtime types).

5) Compiler would auto-rewrite your source code to add/update function
annotations so that you never have to actually write them yourself. This
includes annotations that only the compiler can figure out, like flow
analysis information, code invariants, etc., stuff that would solve a
bunch of problems with separate compilation not having full information
about a function.  Also, the compiler will auto-fix typos for you (and
update the source code) if it makes the code compilable.

6) Completely pay-as-you-go std library / codegen, i.e., if your program
consists of `void main() {}` it should weigh less than 1KB. (In fact, it
should weigh 45 bytes.[1] :-D)  If you writeln("hello world") it should
not pull in code for formatting floats.  Executables would contain the
absolute bare minimum to do what it's supposed to do, not a single byte
more.

7) In-contracts should run in the caller, not the callee.

8) There should be a new standard library function called dwimnwis,[2]
that uses neural networks to predict what the programmer meant rather
than what he actually wrote, and does that instead of what the source
code says.


[1] http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
[2] Do What I Mean, Not What I Said.


T

-- 
I am Ohm of Borg. Resistance is voltage over current.