My two cents

[Martin Nowak]

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
> First, D started as a great new language with the best from all 
> languages. But now D seems more and more conservative. New 
> syntactic sugars aren't added just because they can be found in 
> phobos. (this was Walter's answer when I asked for maybe monad 
> syntactic sugar).
>
> OK, what I'm missing in D and what I think is wrong?
>
> syntactic sugar for:
> tuples
> maybe monad (why we cannot have same syntax as in C#?)
> conditional dereferencing and stuff about that (same as in C#)
> foo?.bar;
> foo?[bar];
> return foo ?? null;

With much stronger typing it's a bit trickier, most things in D 
are not classes/pointers, hence there is no universal null/nil.

> async/await (vibe.d is nice but useless in comparison to C# or 
> js async/await idiom)
> I want to create function returning Promise/Task and await 
> where I want to.
> e.g.
> auto result = device.start(foo, bar); // This is RPC to remote 
> server returning Task!Bar
> // do some important stuff
> return await result; // wait for RPC finish, then return it's 
> result
>
> I want to do this and not any ugly workaround about that.

It's not that hard to add full async/await support to the 
compiler. The code for capturing upvalues is already there to 
support foreach opApply callbacks. We still don't have @nogc 
delegates, but that's also not too much of a hassle.

While it could be implemented, priority isn't too high. At least 
for I/O-bound workloads, the performance gains over stack based 
async is rather small. Would be different for using async/await 
for parallel HPC (http://stellar-group.org/libraries/hpx/).

If you want to run 2 async tasks concurrently with Fibers, just 
use e.g. http://vibed.org/api/vibe.core.core/runTask.

> @trusted, @safe, @system - why we have 3 keywords instead of 
> one? And why it's so complicated to use?
>
> First, we should have one 'unsafe' keyword.
> Second, everything should be safe by default.
> 3rd, if we want to declare @system func, use 'void foo() 
> unsafe;'
> if we want to declare @trusted func, use
> void foo() {
> unsafe {
>
> }
> }

Sounds easy and nice, but isn't compatible with separate 
compilation and headers, which in fact are key to good compile 
times.

> C# properties instead of existing ones.
> function and property should be two different things.
> Calling function without () or assigning to it by = is a ugly 
> behavior and should be avoided.

Different folks, different strokes. Lots of people seem to like 
optional parens, in particular for `arr.map!(e => e ^^ 
2).each!writeln` chains.
Maybe you just need to get used to them. Otherwise write a Linter 
that slaps you whenever you forget them.

> implement this thing from C# (just because it's cool)
> new Foo() {
>   property1 = 42,
>   property2 = "bar"
> };
> Reference counting when we cannot use GC...

WIP

> Commercial usage, shared libraries and stuff
> There isn't any handy tool to download, manage and publish 
> closed source stuff.
> dub is great for simple solutions but useless in big projects 
> with multiple targets, configurations, etc.
> Everything is primary focused on opensource development (but 
> everyone here wants to see D as a next successor of C++ in 
> commercial sphere).

Well, dub is a package manager to share code, so obviously OSS it 
the main target. You can easily `dub add-local` packages or run 
your private registry.
And of course there are various other options like Make, CMake, 
Meson, or Raggae.

> Still cannot easily develop closed source dlls on Windows. On 
> Linux every symbol is public by default, but on Windows not so 
> it's needed to export them manually.

WIP 
(https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP45.md)
Cannot is quite strong, it just requires a bit of work.

> Unable to publish closed source library without workaround and 
> ugly PIMPL design.

Why is that?

For templates and inference the compiler needs to see stuff in 
order to compile them.
This is the same contradiction as with you unsafe block 
suggestion above.

If you know sth. really smart here, make sure to let us know :).

> Add dll/so usage without header files
> (export enums, templates and stuff right into dll/so and let D 
> compiler to import these stuff from it)
>
> like return ref parameters and return functions but is unable 
> to add some basic stuff.

We could do better on communicating our plans. Return ref and 
scope are part of a major effort to transition to manual memory 
management (RC et.al.) without buying into the associated memory 
corruptions (and security issues) that plague C/C++.

====================

As unfortunately with almost any OSS project, we're not that many 
people, and each of us is investing a huge amount of time into 
this.
OTOH we're getting tons of requests, which are often hard to 
prioritize. Most of them are particular interests as well (you 
seem to have an edge for C#).

Would be great if you could attach some estimated costs to each 
of your points, i.e. how much effort does this or that cause for 
you.

Something I want to have for quite a while is a free-form poll 
for features, maybe running 2 weeks or so, to get a better 
understanding of community priorities.

But again your best bet on getting sth. done is working on it, be 
it writing a DIP, organizing the discussion, or actually 
implementing it.