On Friday, 20 October 2017 at 08:09:59 UTC, Satoshi wrote:
>>> > return foo ?? null; would be so much easier.

Definitely the Elvis operator is a small and sometimes useful addition.
https://en.wikipedia.org/wiki/Elvis_operator
Your best bet on getting it, is writing a small DIP, the organize consensus for the exact semantics to get it approved.
https://github.com/dlang/DIPs/

It's seems far from being a high priority though. Actually quite a pity that of the many valid points you mentioned, the majority of the discussion focuses on this triviality.

But as usual, when it's cheap to have an opinion, everyone affords one.
Hence if you want to change sth. get your DIP approved. I'd even volunteer for the compiler implementation of `?:`.

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.

On Friday, 20 October 2017 at 15:38:53 UTC, Martin Nowak wrote:
>
> 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.
>

Maybe once a quarter, ;)

It might help to have some sense of how the main devs time on D is being used. Not in any kind of exact way, more hand-wavy. For instance, if w% of their time is on fixing bugs, x% on maintenance, y% on working towards safety, z% on other stuff they are already doing that I'm not included, then time spent on new features or syntax has to come from somewhere of that. What do you reduce your time on to implement them? That's where it gets tricky. Is elvis operator more important than improving safe/scope/nogc/etc, I think most would say no.

This is the economic way of looking at things. Taking the number of devs and the hours they spend on D as given, how they spend that time is an allocation problem. Walter and Andrei and Martin have in their heads some ideas about what is the best approach. However, when you think of resources (dev D) as finite, then someone would need to be able to show that the new features or syntax are more important than the other things that they are already working on. That's why DIPs.

On Friday, 20 October 2017 at 16:36:28 UTC, jmh530 wrote:
> It might help to have some sense of how the main devs time on D is being used.

Definitely, I currently have no clue what they are on.

> Is elvis operator more important than improving safe/scope/nogc/etc, I think most would say no.

I would say yes. I think safe/scope/nogc/etc are useless given
their bad design, and enormously difficult to get right given our
current constraints. The elvis operator, while trivial and
unnecessary, would be easy to implement correctly and give
a nice little PR boost to show that we care about the people
talking about it.

On Friday, 20 October 2017 at 02:20:31 UTC, Adam D. Ruppe wrote:
> On Friday, 20 October 2017 at 00:26:19 UTC, bauss wrote:
>> return foo ?? null; would be so much easier.
> return getOr(foo, null);

I guess with UFCS you could get:
return foo.PP(null); // vs.
return foo ?? null;

:D

On Fri, Oct 20, 2017 at 06:20:52PM +0000, Random D user via Digitalmars-d wrote:
> On Friday, 20 October 2017 at 02:20:31 UTC, Adam D. Ruppe wrote:
> > On Friday, 20 October 2017 at 00:26:19 UTC, bauss wrote:
> > > return foo ?? null; would be so much easier.
> > return getOr(foo, null);
> 
> I guess with UFCS you could get:
> return foo.PP(null); // vs.
> return foo ?? null;
> 
> :D

You could have this today via a nicely-named UFCS function:

	T orElse(T t, lazy T defaultVal) { return t is null ? defaultVal : t; }

	class C {}
	C defaultC;
	C makeC() { ... }

	auto c = makeC().orElse(defaultC);

You can even UFCS-chain it:

	auto c = makeC().orElse(makeCAnotherWay())
			.orElse(makeCYetAnotherWay())
			.orElse(defaultC);


T

-- 
Stop staring at me like that! It's offens... no, you'll hurt your eyes!

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
> Hi,
> I had been using D for almost 6 years and I want to share my opinion with you.
> I don't want to blame anyone but I'll focus more on bad things and possible improvements.
> And this is just how I see D from my perspective.
> (Sorry for my English, I'm too lazy to take the lessons).
>
>
> 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;
>
> 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.
>
>
> @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 {
>
> }
> }
>
> This fulfills the D's idiom in better way, because we should be defining unsafe sections as small as possible.
>
>
> 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.
>
> implement this thing from C# (just because it's cool)
> new Foo() {
>   property1 = 42,
>   property2 = "bar"
> };
>
>
> Reference counting when we cannot use GC...
>
>
> 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).
>
>
> 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.
>
>
> Unable to publish closed source library without workaround and ugly PIMPL design.
>
> 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)
>
>
>
> For me, it seems like Walter is solving edge case problems like return ref parameters and return functions but is unable to add some basic stuff.
>
>
> Thanks for your time.
> - Satoshi

Interesting proposals, but IMHO, the only ESSENTIAL feature missing in D is the possibility to program in D using a built-in reference-counting based variant of the standard library.

If D really sells itself as a C++ alternative, then it MUST be a true C++/Rust competitor.

So using stuff like strings, slices, maps, reference classes should be made possible without GC.

You just need a few qualifiers to say if a class instance is owned by a reference (behavior by default) or just pointed by a weak reference (i.e a pointer with automatic deferencing).

That ALONE would make D a better competitor to C++ on its grounds.

Add full binary compatibility at the linker level with C++ library and you may now have a real opportunity to "win" the war against C++ and Rust.

Or you can just wait that C++ improves enough (modules, etc) so that D provides too few advantages to be an interesting alternative...

On Friday, 20 October 2017 at 18:11:50 UTC, Adam D. Ruppe wrote:
> [...] The elvis operator, while trivial and
> unnecessary, would be easy to implement correctly and give
> a nice little PR boost to show that we care about the people
> talking about it.

If you go by there, the safe navigation operator would probably even easier to implement than the elvis one.

On Friday, 20 October 2017 at 19:18:15 UTC, Ecstatic Coder wrote:
>
> Interesting proposals, but IMHO, the only ESSENTIAL feature missing in D is the possibility to program in D using a built-in reference-counting based variant of the standard library.
>

Look at the goals for H2 2017
https://wiki.dlang.org/Vision/2017H2
The top three things: 1) @safety, 2) @nogc, 3) betterC. Under #2, it specifically says safe reference counting. It's getting worked on...

On Friday, 20 October 2017 at 19:54:09 UTC, user1234 wrote:
> On Friday, 20 October 2017 at 18:11:50 UTC, Adam D. Ruppe wrote:
>> [...] The elvis operator, while trivial and
>> unnecessary, would be easy to implement correctly and give
>> a nice little PR boost to show that we care about the people
>> talking about it.
>
> If you go by there, the safe navigation operator would probably even easier to implement than the elvis one.

How about somebody implements the functionality, such as with what H.S. Teoh describes, and gets it added into phobos, maybe std.typecons b/c that's where nullable is?

If it's in phobos and people find themselves using it all the time, then it might make sense to push for it to get the syntax added.