www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why are some types from std not in the core of the language?

reply mesni <mensikovk817 gmail.com> writes:
D has AA and arrays built into the language and runtime. But why 
are sumtype, arrays/smart pointers using custom allocators, 
nullable, tuple at the expense of std? Everything listed in this 
article https://dlang.org/articles/builtin.html applies to them. 
I think this can be done as something like an optional extension 
in the compiler.
Jun 09 2022
next sibling parent reply mesni <mensikovk817 gmail.com> writes:
On Friday, 10 June 2022 at 01:08:02 UTC, mesni wrote:

 D has AA and arrays built into the language and runtime. But 
 why are sumtype, arrays/smart pointers using custom allocators, 
 nullable, tuple at the expense of std? Everything listed in 
 this article https://dlang.org/articles/builtin.html applies to 
 them. I think this can be done as something like an optional 
 extension in the compiler.


By the way, all modern system languages ​​(zig, odin) have such 
types built in. And D, due to the need to maintain compatibility 
(although it still breaks it), moves away from the roots and 
follows the path of C++
Jun 09 2022
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 10 June 2022 at 01:16:10 UTC, mesni wrote:

 On Friday, 10 June 2022 at 01:08:02 UTC, mesni wrote:

 D has AA and arrays built into the language and runtime. But 
 why are sumtype, arrays/smart pointers using custom 
 allocators, nullable, tuple at the expense of std? Everything 
 listed in this article https://dlang.org/articles/builtin.html 
 applies to them. I think this can be done as something like an 
 optional extension in the compiler.


 By the way, all modern system languages ​​(zig, odin) have such 
 types built in. And D, due to the need to maintain 
 compatibility (although it still breaks it), moves away from 
 the roots and follows the path of C++


To quote [my own post][1] on the subject:


 The dirty secret here is that the code quality of the DMD 
 fronted has deteriorated to the point where it is basically 
 impossible to do a correct, complete implementation of any 
 non-trivial language feature. So we can either have a library 
 solution that works, but has ugly syntax; or we can have a 
 language solution that has nice syntax, but doesn't work.


Most contributors would rather build something that's ugly and 
correct than something that's beautiful and broken, so they 
mostly choose to write new libraries instead of new language 
features.

[1]: 
https://forum.dlang.org/post/jccdguayqqziwaxnhxts forum.dlang.org
Jun 10 2022
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 10 June 2022 at 13:21:09 UTC, Paul Backus wrote:

 the code quality of the DMD

 fronted has deteriorated to the point where it is basically 
 impossible to do a correct, complete implementation of any 
 non-trivial language feature.




Is it because there is no `class encapsulation`?
Jun 10 2022
next sibling parent zjh <fqbqrr 163.com> writes:
On Friday, 10 June 2022 at 14:00:13 UTC, zjh wrote:


 Is it because there is no `class encapsulation`?


What can be done to improve the willingness of contributors to 
contribute?
Jun 10 2022
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 10 June 2022 at 14:00:13 UTC, zjh wrote:

 On Friday, 10 June 2022 at 13:21:09 UTC, Paul Backus wrote:

 the code quality of the DMD

 fronted has deteriorated to the point where it is basically 
 impossible to do a correct, complete implementation of any 
 non-trivial language feature.




 Is it because there is no `class encapsulation`?


No, it's because there's too much shared mutable state, and not 
enough immutable objects and pure functions.
Jun 10 2022
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 10 June 2022 at 14:14:46 UTC, Paul Backus wrote:


 No, it's because there's too much shared mutable state, and not 
 enough immutable objects and pure functions.



Can it be improved by splitting large `source files` into small 
files?
I think should refactor `'dmd'` aggressively.
Jun 10 2022
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 10 June 2022 at 14:24:06 UTC, zjh wrote:

 On Friday, 10 June 2022 at 14:14:46 UTC, Paul Backus wrote:


 No, it's because there's too much shared mutable state, and 
 not enough immutable objects and pure functions.



 Can it be improved by splitting large `source files` into small 
 files?
 I think should refactor `'dmd'` aggressively.


The size of the source files is not the problem.
Jun 10 2022
parent max haughton <maxhaton gmail.com> writes:
On Friday, 10 June 2022 at 15:24:08 UTC, Paul Backus wrote:

 On Friday, 10 June 2022 at 14:24:06 UTC, zjh wrote:

 On Friday, 10 June 2022 at 14:14:46 UTC, Paul Backus wrote:


 No, it's because there's too much shared mutable state, and 
 not enough immutable objects and pure functions.



 Can it be improved by splitting large `source files` into 
 small files?
 I think should refactor `'dmd'` aggressively.


 The size of the source files is not the problem.


Wouldn't hurt though.
Jun 10 2022
prev sibling next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 10 June 2022 at 01:08:02 UTC, mesni wrote:

 D has AA and arrays built into the language and runtime. But 
 why are sumtype, arrays/smart pointers using custom allocators, 
 nullable, tuple at the expense of std? Everything listed in 
 this article https://dlang.org/articles/builtin.html applies to 
 them. I think this can be done as something like an optional 
 extension in the compiler.


So everyone can feel extremely clever coding their own with 
recursive templates

Also generally speaking the apis people pick for these things are 
awful, I rather have more meta programming tools
Jun 09 2022
prev sibling next sibling parent IGotD- <nise nise.com> writes:
On Friday, 10 June 2022 at 01:08:02 UTC, mesni wrote:

 D has AA and arrays built into the language and runtime. But 
 why are sumtype, arrays/smart pointers using custom allocators, 
 nullable, tuple at the expense of std? Everything listed in 
 this article https://dlang.org/articles/builtin.html applies to 
 them. I think this can be done as something like an optional 
 extension in the compiler.


I'm not sure if AA and arrays are built in the D language. Not 
even classes are built into the language. If I'm not mistaken AA, 
arrays and classes are implemented using meta programming and 
compiler hooks.

It's a matter of definition, yes classes, AA, arrays are part of 
the core language but they aren't really implemented as a core of 
the language.
Jun 10 2022
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Friday, 10 June 2022 at 01:08:02 UTC, mesni wrote:

 D has AA and arrays built into the language and runtime. But 
 why are sumtype, arrays/smart pointers using custom allocators, 
 nullable, tuple at the expense of std? Everything listed in 
 this article https://dlang.org/articles/builtin.html applies to 
 them. I think this can be done as something like an optional 
 extension in the compiler.


That's one of the reason i'm more and more using Zig these days

I don't have to import some random bullshit to have tagged union 
with pattern matching

They'll also have a language server built into the compiler as 
well as binary patching (meanwhile nobody merge PRs in DCD, and 
it ends up being a rotten software that is CRUCIAL to D adoption)

D is a superior language, BY FAR, but these little things are 
what makes the difference when you just want to appreciate a 
language without people telling you to import std.sumtype to have 
tagged union

Two different mindset, at the end, i pick what's make me the less 
annoyed in the long run, and that's zig's tagged union

Really we need to wake up and make D better



Our competitive features are becoming the norm, and we are 
failing behind in many other crucial areas
Jun 12 2022
parent reply zjh <fqbqrr 163.com> writes:
On Sunday, 12 June 2022 at 13:40:16 UTC, ryuukk_ wrote:


 Our competitive features are becoming the norm, and we are 
 failing behind in many other crucial areas


You're right, `d'` need depends on the strength of the 
organization. `DMD` needs radical refactoring.
`The source code` is too bad. `Divide` large files into `small 
files` and do `class encapsulation`!
Jun 12 2022
parent reply zjh <fqbqrr 163.com> writes:
On Sunday, 12 June 2022 at 14:29:41 UTC, zjh wrote:


 `DMD` needs radical refactoring.
 `The source code` is too bad. `Divide` large files into `small 
 files` and do `class encapsulation`!


D should stop `'D2'`, develop `'D3'` and radically refactor 
`'DMD'` for `'D3'`.

What should we do if even `experts` can not 'correctly and 
completely' realize new features?
Jun 12 2022
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Sunday, 12 June 2022 at 14:34:23 UTC, zjh wrote:


 What should we do if even `experts` can not 'correctly and 
 completely' realize new features?


The reason why there are few contributors is that the code can 
not realize `class level encapsulation`!
Without `encapsulation`, the code is a `mess`.

A bunch of `thousands of` lines of `code files`, how to 
contribute?
Why not split it into `dozens of` small files into hundreds lines 
files?
Jun 12 2022
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Sunday, 12 June 2022 at 14:46:29 UTC, zjh wrote:


 Without `encapsulation`, the code is a `mess`.

 A bunch of `thousands of` lines of `code files`, how to 
 contribute?
 Why not split it into `dozens of` small files into hundreds 
 lines files?



We all know the story of `'VIM' and 'Nvim'`. What `'d'` needs is 
`'radical'` change, and `'DMD'` needs to be completely 
`reconstructed`!
At this time, it `makes sense` to completely `refactor` .
Keep `'D2'` for maintenance version `only`!
Only through `'thorough'` reconstruction can activat people's 
interest in participating in `'DMD'`!
Jun 12 2022
parent zjh <fqbqrr 163.com> writes:
On Sunday, 12 June 2022 at 15:05:55 UTC, zjh wrote:


 We all know the story of `'VIM' and 'Nvim'`. What `'d'` needs 
 is `'radical'` change, and `'DMD'` needs to be completely 
 `reconstructed`!
 At this time, it `makes sense` to completely `refactor` .
 Keep `'D2'` for maintenance version `only`!
 Only through `'thorough'` reconstruction can activat people's 
 interest in participating in `'DMD'`!



`C++` was revived through the radical `'c++11'`
Python has been revived through the radical `'PY3'`
`D` also needs `'D3'` to revive!
The earlier the radical refactoring `dmd`, the better.
Jun 12 2022
prev sibling parent reply Zoadian <no no.no> writes:
On Sunday, 12 June 2022 at 14:46:29 UTC, zjh wrote:

 On Sunday, 12 June 2022 at 14:34:23 UTC, zjh wrote:


 What should we do if even `experts` can not 'correctly and 
 completely' realize new features?


 The reason why there are few contributors is that the code can 
 not realize `class level encapsulation`!
 Without `encapsulation`, the code is a `mess`.

 A bunch of `thousands of` lines of `code files`, how to 
 contribute?
 Why not split it into `dozens of` small files into hundreds 
 lines files?


"class level encapsulation" is absolutely unnecessary. don't put 
your class into module scope if you don't want it's internals 
exposed to the module in the first place.
Also it's not the problem with dmd's code base. dmd lacks 
documentation, and has mutablility all over the place.
Splitting files into smaller modules wouldn't hurt though
Jun 12 2022
parent forkit <forkit gmail.com> writes:
On Sunday, 12 June 2022 at 15:34:53 UTC, Zoadian wrote:

 ...
 "class level encapsulation" is absolutely unnecessary.
 ...


You heard it first here folks.

This should become the D motto.
Jun 12 2022
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 12 June 2022 at 14:34:23 UTC, zjh wrote:

 D should stop `'D2'`, develop `'D3'` and radically refactor 
 `'DMD'` for `'D3'`.


People have to agree on what D3 would be like, meaning: write a 
spec that they agree on.
Jun 12 2022
next sibling parent forkit <forkit gmail.com> writes:
On Sunday, 12 June 2022 at 17:29:27 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 12 June 2022 at 14:34:23 UTC, zjh wrote:

 D should stop `'D2'`, develop `'D3'` and radically refactor 
 `'DMD'` for `'D3'`.


 People have to agree on what D3 would be like, meaning: write a 
 spec that they agree on.


No. D3 will be a fork... too many people stuck in their ways at 
the moment :-(
Jun 12 2022
prev sibling parent zjh <fqbqrr 163.com> writes:
On Sunday, 12 June 2022 at 17:29:27 UTC, Ola Fosheim Grøstad 
wrote:


 People have to agree on what D3 would be like, meaning: write a 
 spec that they agree on.


If everyone agrees, do it
Everyone disagrees each other. then provided a switch.

`DMD` source code even `experts` can't stand it, so it must be 
radical `refactored`!
Jun 12 2022