On Saturday, 21 October 2017 at 19:39:31 UTC, Andrei Alexandrescu wrote:
> [...]
> Using the topic of the Elvis operator as a running example, a good DIP would contain motivation such as:
>
> * Present evidence of the successful use of ?: in other languages

I'm not sure that people talked much about the elvis operator (which was introduced in the topic by M.Nowak). In the first message were mentioned the null coalescence operator "??" and the safe navigation one "?." . The later was more discussed.

On 10/21/17 11:52, bitwise wrote:
> On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
>
>> async/await (vibe.d is nice but useless in comparison to C# or js
>> async/await idiom)
>
>
>> Reference counting when we cannot use GC...
>
>
> If I understand correctly, both of these depend on implementation of
> 'scope' which is being worked on right now.
>
> I think reference counting needs 'scope' to be made safe. RC also
> benefits from scope in that many of the increments/decrements of the ref
> count can be elided. The performance gain can be significant, and even
> more so when you use atomic reference counting (like C++ shared_ptr) for
> thread safety.
>
> Async/Await needs to allocate state for the function's local variables.
> When it's detected that the function's state/enumerator won't escape
> it's current scope, it can be put on the stack, which is a pretty big
> optimization.
>
> I should also note that, RC has been formally acknowledged as a future
> goal of D, but as far as I know, async/await has not.
>

Walter has stated numerous times both here and at conferences that Async/Await is definitely a goal. However, it's not as high a priority as the @safe/@nogc work so it hasn't made it to any official vision statement. Also I just talked to him offline about it, and he would need some serious help with it. He doesn't know how to do the compiler rewrite, and there a number of tricky situations one has to deal with. As much as I like Async/Await, I agree that the current plan has higher priority.

I'll probably start poking around Async/Await when I can clear the decks a bit of paid work. But that could be a while. :(

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On 10/21/2017 1:40 PM, Adam Wilson wrote:
> Walter has stated numerous times both here and at conferences that Async/Await is definitely a goal. However, it's not as high a priority as the @safe/@nogc work so it hasn't made it to any official vision statement. Also I just talked to him offline about it, and he would need some serious help with it. He doesn't know how to do the compiler rewrite, and there a number of tricky situations one has to deal with. As much as I like Async/Await, I agree that the current plan has higher priority.
> 
> I'll probably start poking around Async/Await when I can clear the decks a bit of paid work. But that could be a while. :(

Async/Await can be implemented by rewriting ("lowering") the code to simpler D code. Implementing it awaits (!) figuring out just what those rewrite rules are.

On Saturday, 21 October 2017 at 20:02:28 UTC, user1234 wrote:
> I'm not sure that people talked much about the elvis operator (which was introduced in the topic by M.Nowak). In the first message were mentioned the null coalescence operator "??"

What's the difference between `?:` and `??`?

As far as I can tell, they'd do the same thing in most cases.

On Saturday, 21 October 2017 at 21:45:11 UTC, Adam D. Ruppe wrote:
> On Saturday, 21 October 2017 at 20:02:28 UTC, user1234 wrote:
>> I'm not sure that people talked much about the elvis operator (which was introduced in the topic by M.Nowak). In the first message were mentioned the null coalescence operator "??"
>
> What's the difference between `?:` and `??`?
>
> As far as I can tell, they'd do the same thing in most cases.

Elvis operator returns LHS if LHS is true, otherwise RHS
Null coalescing operator returns LHS if LHS is not null, otherwise RHS

But since in D nullable values can be interpreted as booleans you're right "?:" would do the same as "??" and even more. Actually "?:" is preferable (which i didn't realize in first place :/).

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.
>
>

These guys are old now and don't have the drive they used to have. It happens, part of life. Unfortunately they do not realize this and do not want to pass the torch. I wouldn't expect anything major for D any more unless something significant changes in the management. D is stagnate, unfortunately and will almost surely never be a major player. It's unfortunate but D has a lot of problems. It is not commercially viable for the mass market. D is a hobby language and will remain that way for the majority of it's users. This is almost entirely due to the mind set you have. It's a lot of work to bring D up to par with the other languages and there seems very little interest in actually making that happen.

Walter only see's what he wants. He looks at D and does not see the flaws like  mother looking at her ugly baby. If one always looks at the pros and ignores the cons then anything looks good. D has a lot of great things but also a lot of bad things... until those bad things are fixed D won't go anywhere... it would be nice, at least, if the management would be objective about the bad things instead of sweeping them under the rug.  Faking it until you make it is not an option here.

On 10/20/2017 11:11 AM, Adam D. Ruppe wrote:
> 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.

Whiling away the hours, conferring with the flowers, consulting with the rain.
My head I'm scratching while my thoughts are busy hatching.

On Sunday, 22 October 2017 at 01:02:06 UTC, EntangledQuanta wrote:
> On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
>> ...
>
> These guys are old now and don't have the drive they used to have. It happens, part of life. Unfortunately they do not realize this and do not want to pass the torch. I wouldn't expect anything major for D any more unless something significant changes in the management.

I thought the actual problem is just that dlang has not enough developer resources. Being young doesn't fix that. Wasn't the staff old already when D2 came out?

ps, also i want something similar to this in D:
>> new Foo() {
>>   property1 = 42,
>>   property2 = "bar"
>> };
it might solve things better than named parameters  https://wiki.dlang.org/DIP88

On Sunday, 22 October 2017 at 07:23:14 UTC, meppl wrote:
> On Sunday, 22 October 2017 at 01:02:06 UTC, EntangledQuanta wrote:
>> On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
>>> ...
>
> ps, also i want something similar to this in D:
>>> new Foo() {
>>>   property1 = 42,
>>>   property2 = "bar"
>>> };
> it might solve things better than named parameters  https://wiki.dlang.org/DIP88

Well the thing is. This already exist for structs and I have always wondered why it doesn't exist for classes.

See:
https://dlang.org/spec/struct.html#static_struct_init

The example:

```
struct S { int a; int b; int c; int d = 7;}
static S x = { a:1, b:2};            // c is set to 0, d to 7
static S z = { c:4, b:5, a:2 , d:5}; // z.a = 2, z.b = 5, z.c = 4, z.d = 5
```

So it would make sense if classes supported it in the same way like:

```
class S { int a; int b; int c; int d = 7; }

static S x = new { a:1, b:2 };

// static auto x = new S { a:1, b:2 };

static S z = new { c:4, b:5, a:2, d:5 };

// static auto z = new S { c:4, b:5, a:2, d:5 };
```

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:

> syntactic sugar for:
> tuples

as far as i know there was the will to implement tuples in the language, but there is still a deprecation in the way:
https://dlang.org/deprecate.html#Using%20the%20result%20of%20a%20comma%20expression