Re: The D Programming Language Vision Document
On Tuesday, 5 July 2022 at 12:34:57 UTC, ryuukk_ wrote: GC is one of D's strength because it is optional, not making core APIs bing-your-own-memory-allocation-strategy through nogc or allocators, is making it no longer optional, which is no longer a strength imo You don't want GC when you do microcontroller development, so as a result core APIs (most of them) becomes useless, moving forward that should make the story better for everyone Which becomes a strength again! Sure, I agree with you. I think I was just being pedantic. :)
Re: The D Programming Language Vision Document
On 05/07/2022 11:49 PM, ryuukk_ wrote: Hopefully that includes proper built in Tagged Union, non OOP people need that otherwise we are stuck in C's era of programming C's era of programming also happens to coincide with ML which had tagged unions ;) The C family has never been very expressive.
Re: The D Programming Language Vision Document
On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote: On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: You can find the final draft of the high-level goals for the D programming language at the following link: https://github.com/dlang/vision-document Under 'Memory safety': Allow the continued use of garbage collection as the default memory management strategy without impact. The GC is one of D's strengths, and we should not "throw the baby out with the bath water". Under 'Phobos and DRuntime': @nogc as much as possible. Aren't these the polar opposites of each other? The GC is one of D's strengths, yet we should avoid it as much as possible in the standard library. Then it's not part of D's strengths. GC is one of D's strength because it is optional, not making core APIs bing-your-own-memory-allocation-strategy through nogc or allocators, is making it no longer optional, which is no longer a strength imo You don't want GC when you do microcontroller development, so as a result core APIs (most of them) becomes useless, moving forward that should make the story better for everyone Which becomes a strength again!
Re: The D Programming Language Vision Document
Pattern matching
Hopefully that includes proper built in Tagged Union, non OOP
people need that otherwise we are stuck in C's era of programming
We can, and we should do better (import std.sumtype is
embarrassing when other languages have it built in without
template soup, i still refuse to touch it)
Tuples
Awesome! hopefully they become built in and more integrated
Async/await
This one will be tricky, done well means it scale from 0 to
hearo, meaning i should be able to use it without the need of a GC
Hopefully it's not one of these import `std.concurency: async,
await, frame;`
Stronger traits
That's awesome to hear, metaprogramming is one of D's strength
On the tooling part:
A language server is long overdue..
https://pkg.go.dev/golang.org/x/tools/gopls
https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html
https://rust-analyzer.github.io/
The one we have right now (serve-d) is nice, but uses the same
backend as every other projects (DCD), and this project haven't
evolved in years, the moment you step into template territory, it
falls short ``T get(T)() { return T.init } auto myInt =
get!int;`` it'll not know what myInt is.. wich is a shame when
that feature is D's signature
A better debugging story is also essential, without having to use
external (incomplete) files like:
https://github.com/Pure-D/dlang-debug
msvc, clang, gcc: they should know what D types are, and they
should be able to step properly into D syntax without the need of
the user to do weird things
Zig is a young language and yet has a better debugging story
Onto the phobos/druntime:
That's nice to hear that the goal is to reduce inter module
dependencies
Core APIs should be made independent and VERY simple, this allows
them to be easily ported to other platforms, easier to extend
I am sad that no word on the Allocator API, moving forward i
personally think APIs that use memory should be required to ask
for an Allocator and do their allocation using it, and only it
A default GCAllocator could be used if none provided, this allows
users of all kind to enjoy the APIs without having to complain
about the GC or their inability to integrate the APIs in their
game engine for example
--
Overall this document is super encouraging, thanks for making it,
D finally have a long term roadmap!
Hopefully this allows everyone to align and coordinate their
efforts
I wish i could help, i tried, but language programming is
definitely not my cup of tea, hopefully you guys are not sick of
my suggestions
A language is about allowing user to express their intent, making
it easier for them to achieve that goal is a priority, compiler
internal difficulties should not prevent language improvements,
compiler internals doesn't exist from the user point of view
Winners of the April 1st - July 1st 2022 Bugzilla Cycle
Hello everyone, It is my pleasure to announce that the winners of the 2nd bugzilla cycle of the year are: 1. BorisCarvajal - 370 points 2. MoonlightSentinel - 135 points 3. FeepingCreature - 120 points Congratulations! The cycle standings are here: https://bot.dlang.io/contributor_stats_cycle The overall standings hierarchy, which counts all the points that have been collected since the system was put in place, is here: https://bot.dlang.io/contributor_stats A new bugzilla cycle has started on the 1st of July and will end on the 30th of September. Cheers, RazvanN
Re: The D Programming Language Vision Document
On Monday, 4 July 2022 at 16:12:35 UTC, rikki cattermole wrote: https://www.unicode.org/Public/14.0.0/ucd/NormalizationTest.txt Argh, linking to large files... My implementation passes this :3 It should be complete test cases. Well, you also have to test for the cases that should not trigger any change, and also for sequencing/parsing bugs. So, not complete, but a good start.
