On Wednesday, 27 October 2021 at 17:48:49 UTC, Steven Schveighoffer wrote:

Exactly. How can one make this work without breaking introspection and type equality?

On Wednesday, 27 October 2021 at 18:22:32 UTC, jmh530 wrote:

Importing a package relative to current module in path. For example, being able to import std.range from std.algorithm.iteration without specifying std. The syntax might be import package.package.range, where package means the parent module.

The idea is the same as with relative symbolic links (for example ../bin/dmd), as opposed to absolute symbolic links (say /home/walter/d/bin/dmd)

On Wednesday, 27 October 2021 at 18:41:02 UTC, Dukc wrote:

Yeah, I was thinking more of the second example. What tripped me up is that manipulating directories on a relative basis has a current working directory that you are relative to. So for instance, something like from std.algorithm.iteration import ../../range made a bit more sense to me, but that seemed a bit messy...

I think this version schema is fundamentally wrong and looks to me like a quick way to the D1 standard library mess.

Having/installing multiple std versions bundled with a DMD/druntime release has written disaster all over it.

Let me be clear, phobos needs work (breaking changes).
I'm not denying that.

But this feels like we are scared of repeating the D1 to D2 PR disaster, and do a kind of soft major version break.
Only this way we can say: "but we didn't break the api its still D2"

We have DMD 2.0100 coming up.
Just look at that silly number.

When I have to explain to somebody what that number means plus an additional std v2 thing, they have installed and compiled the rust hello world before I'm done.

Lets be bold!

Lets us call what would be D release 2.0100 "D" The semver is 100.0.0

I have been using D2 since ~2009 and IMO it had enough breaking changes to call it version 100.0.0.
There is one number that describes D and its std.
When a symbol is no longer there in phobos, we increment the major version number.
When we add something to phobos we increment the minor number version number.
Here comes the somewhat tricky part, when dmd can not compile or a test now fails for the 50 most popular dub packages that worked with dmd N-1 we increment the version number.
We continue with the current release cycle, but the SemVer number is computed by a small script.
If we think a change warrants a major increment we can increment, but we can never not do an increment if we break something.
The changelog would list what broke/was removed.
Again, this can be done by a script.
The breakage testing for phobos, should not be clever, iff a public declaration is removed or changed it is a breaking change.
This is 2021 why is a human deciding what the version number is if the computer can do it.

And then lets have a proper vision for D, and not only small technical improvements.
I understand that we can't direct people to work on things in our community, but we can ask them.

So here it goes.

marketing

First we call D: "D the best programming language"

Obviously, that is correct in IMHO, but even if people disagree, they are at that point talking about D.
We lure them in with clickbait, but than doing anything, in any other language takes longer than doing it in D.

D should be the glue that makes the world go round.

phobos/druntime

Why is https://github.com/symmetryinvestments/autowrap not in phobos, and why doesn't it support, WASM, python, typescript, go, and haskell?

If I want to call this one function out of the python std, the only thing in my way must be the fact that I have forgotten how save a file in emacs, because I'm doing it on a friends computer how is using emacs.

If I have to write more than

static import std.python;

auto result = std.python.thisOneFunction(a_bunch_of_complex_arguments);

we have failed.

I want to say, "ah you want to call a scikit function from D. No problem just right this line"
"But you have to call haskell first to get the data pre-processed, sure just at this line". No dub package required, just a D compiler and phobos.

phobos needs to have an event loop library included.
golang has go routines inside the language, we at least need something not much worse in phobos.

Support for yaml, toml, ini, json-schema, etc. in phobos.

When I have a json-schema, or whatever the equivalent is in yaml or any of the other, I want to write mixin(jsonSchemaBuild(import("path_to_schema_file.json"))
and have classes that represent the AST of the schema and a parser that turns json into those classes.
100% of people that see this feature will not care that it uses the GC.

dmd

Why do I have to call dmd, ldc, or gdc when I want a different backend to generate code. Isn't that what shared libraries are for?
Why can't I call dmd with --backend=llvm and compile with llvm instead of the dmd's backend.
Just think about this, do we really want people to understand that we have a D version 2.0100 with std version 2 or 3, and you have three compiles that support three different version of the language plus three different versions of the std, with all having different cli arguments.
No thank you, I'll just write some js and use node.js.

WASM: If I have a library or program, I need to be able to say --backend=XXX --outputType=WASM.
No betterC, no nogc, no excuses, it just needs to work. And additionally, it needs to put out a typescript file that does the converting of "json to D in WASM and back again" for you.
All without installing anything other than the D compiler and phobos.

The D compiler needs to be a file watcher daemon thing.
It is 2021 I have 64GB of memory, why is dmd still being split up in phases like its 1970 and all I have is a couple KB of RAM.
dmd is fast sure, but have you tried dart's or svelte's compiler.
The D compiler should be a diff compiler, were unchanged source is not lexed, not parsed, not semantically checked, nor ir generated.
When I work on phobos and press CTRL-S, the unittest's for phobos should start running before the keyUp event has received by my editor.

Why do I have to wait for assembler to be linked when I want unittest to run.
The D compiler daemon should execute some VM IR. This is linked to the --backend=XXX --outputType=SOME_VM switches from before.

Also, when the compiler stores all dependencies between functions and types in memory, it can also keep track of which unittest dependents on what code.
So when I change something that only has one unittest depending on it, only that test should be run.
Assuming, I didn't do anything stupid in the unittest, I would expect the unittest to have finished before my editor gets the keyUp event from pressing CTRL-S.

The compiler daemon, needs to support lsp perfectly.
I know you don't need that, because you know all the functions by heart and "real" programmers don't need auto complete.
But you are wrong and they do. Just look at web crowd is doing.
Developers that use this forum is not our target audience.

The features of that daemon need to be so good that they drive the development of the lsp protocol.
So hard indeed, that all other languages have to stub out the new features of the protocol with assert(false, "Impossible to implement") for years to come.

e.g. Before the keyUp event reaches my editor, I want the unittest line coverage changes to appear left of the line numbers in the file I just saved.

Doing a "normal" dub build will not be harder with this compiler daemon, but doing dub build that uses all my 8 cores without doing work twice will be easier.
Doing a dub build for dmd/druntime/phobos in release mode, needs to take less than a second.

Meta

Move everything to github.
Maybe bugzilla has features github does not, but github has 10^6 more users than dlang's bugzilla.
At 10^2 we should have stop caring about features.
The casual user that finds a bug is not going to create an bugzilla account to create an issue.

Let's use milestones in github to express our aims/vision for the language.
E.g. the WASM milestone would link to all the issues related to WASM.
If "average rust user" wants to know what D's story is; simply look at the milestone. Easy to find, easy to contribute to.

Sorry for the rant.

I forgot something:

cross platform

When I write a library to do X.

It has to work on the js,wasm,android,windows,linux,ios without every thinking about that this could be a challange.
The only thing I have to do, must be to write

--output=js,wasm,android,windows,linux,ios

anything less and we have failed.

On Thursday, 28 October 2021 at 08:50:31 UTC, Robert burner Schadek wrote:

Developers that use this forum is not our target audience.

+1

On Thursday, 28 October 2021 at 08:50:31 UTC, Robert burner Schadek wrote:

While your ideal world is basically lala-land, you know, I kind of wished I lived in it.

I really appreciate this vision, but from experience of lurking this forum, I can tell you that, particular the older programmers, won't see much worth in a lot of your suggestions regarding the compiler changes (assuming we'd ever even have the manpower to make it possible in the first place).

I'm not going to spend much time going "but ackstually" and refute your points, since I'm going to be treating this as an "in a perfect world" post. So I'll mostly be sharing my own thoughts alongside yours.

But we've become scared of the very word "breaking change", hence why baggage like @property are likely here to stay :(

Coincidentally I was thinking about this today, but again, I doubt there's enough people who see any worth on fixing the versioning number to something a bit more... sane.

2.100 could be something special, instead of just a normal release with a nice, round number.

Here we now enter lala-land.

I believe that's similar to how the vision documents went. "Here's a wishlist, please-maybe-possibly-if-you-want-to do it Community, best of luck and lots of love - from, the D foundation"

D best programming language ;)

I'm kind of uncertain that'd work, but it's an interesting idea anyway.

static import std.python;

auto result = std.python.thisOneFunction(a_bunch_of_complex_arguments);

That's a very interesting vision... "D, the language to unite them all".

"But you see, does it cover @nogc nothrow pure const inout @safe -betterC all at the same time? No? Rejected!"

or

"What do you mean it needs to use the GC for more than just exceptions? Haven't you heard, we don't do GC anymore because it's scary to the C++ programmers."

I understand the sentiment, but the compilers are all at different levels of support in terms of which version of the language they support.

I mean, ideally it would be nice to have a single, unified compiler, but I feel there's many obstacles in the way for this to actually happen.

Now this is ambition. Unfortunately, as I said, many here likely don't see any value in this. (disregarding the huge amount of work that'd have to go into making this possible in the first place that someone would have to volunteer to champion)

I dream of the day we get a compiler-as-a-library completion service, so maybe things like UFCS and templated types can be autocompleted <3~~

As ok as code-d is, it can be a real PITA when it's only able to work a quarter of the time because it's completely incapable of handling templates in any shape or form.

Meanwhile in Go, F#, C#, Java, Python, JS, TS, even CSS... I go myobj. and get the full API + doc comments.

^^^^^^^^^^^^^... who is our target audience exactly, because I couldn't actually tell you.

Wasn't there some kind of initiative at some point to port the bugzilla issues over to Github issues? I wonder what happened with that.

I love these kinds of "in a perfect world" posts, because at the very least it can spark ideas in the direction things could go.

Rants in general can be very fun and somewhat enlightening to read.

If only posts like this could come from those who have the power, time, and motivation to organise a strong, coherent, unified vision. And if only we had the manpower to make our strongest wishes come true.

A huge restructuring, a complete rebrand, an extreme focus on developer tooling, language integration baked into the std. Some possibly exciting things, but reality generally hates this sort of excitement, and rewards it with a coin flip.

Thank you for this post, will be exciting to see what discussion this sparks though I suspect it won't be as positive a response as I'd hope for.