On Wednesday, 16 October 2019 at 12:01:09 UTC, Russel Winder wrote:
> There is one and only one acceptable formatting of all Go code. The formatters enforce this.

That's exactly the reason why I discarded Go when I was looking for a new language. I don't want to wear that corset (and several others Go imposes on it's programmers).

Just for not being missunderstood: I like to have an unique style for Phobos and I'll accept and use what ever it is if it's not completely off the marks (the current one is quite close to what I normally use, though). But for my own projects I want to be able to use my style.

On Wednesday, 16 October 2019 at 00:33:20 UTC, neikeq wrote:
> Regarding interop with C++, what are your thoughts on tools like Calypso? It supports most C++ features, including advanced stuff like template instantiation, and it seems to be under active development: https://github.com/Syniurge/Calypso

What is the state of Calypso? The last release was in 2014. This is also the latest tag that was created. Development on master stopped in 2018. The most recent commits were on branch. I would have missed that from a cursory look at the commit history (you have to switch branches to notice!). I don't know when it was last sync'ed with LDC. If I wanted to use it, how would I even go about that? How do I get a version that is compatible with recent versions of D and works / is supported?

My point is: the publicly visible state of the project isn't very encouraging for potential users.

On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:
> On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:
>> [...]
>
> I will put this here: https://rawgit.com/wilzbach/state-of-d/master/report.html
>
> Summary (community profile/expectations/disappointments):
> - Desktop applications as main area of development;
> - Linux as preferred operating system;
> - Dub as building tool;
> - Visual Studio Code as main editor;
> - Missing language features (tuples, named arguments, string interpolation)
> - Phobos is not intuitive
> - @nogc phobos
> - json serialization;
> - missing phobos important modules;
> - poor compiler error messages;
> - poor debugging experience;
> - @safe is expected to be default;
> - not enough third party libraries;
> - lack of progress on DIPs;
> - ranges are the best;
> - spaces, not tabs :)
>
> I don't necessarily endorse this list (e.g. I sincerely hate dub), but the D Vision seems to ignore it. And I find this more than wrong, personally perceiving it as "we don't care about your opinion, we have our own agenda, get lost".

This effort is lovely. We need must listening and acting on people's suggestion so that they can feel at home and open their mind to work sincerely. Identity is the first thing in human relationship

On Wednesday, 16 October 2019 at 12:01:09 UTC, Russel Winder wrote:
>> AFAIK nearly everybody uses dub. What else would you like to see in this area?
>
> Something much less like Dub and a lot more like Cargo.

And how exactly is dub not close enough to what cargo provides?

On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:
> On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:
>> [...]
>
> I will put this here: https://rawgit.com/wilzbach/state-of-d/master/report.html
>
> [...]

Which parts of that survey would you like the vision to include?

On Wednesday, 16 October 2019 at 17:40:42 UTC, Atila Neves wrote:
> On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:
>> On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:
>>> [...]
>>
>> I will put this here: https://rawgit.com/wilzbach/state-of-d/master/report.html
>>
>> [...]
>
> Which parts of that survey would you like the vision to include?

Given that the community has already spoken, I think the onus is on the language maintainers at this point to take the results into account (or not).

For example, I could say which items I, personally, think are the most important--but I've already taken the survey. My answers are there, in the data, along with everyone else's. If the language maintainers care what I and the rest of the community thinks, that's where they ought to look. (And if they don't, then why ask a question like the one above in the first place?)

On Wednesday, 16 October 2019 at 11:14:30 UTC, Atila Neves wrote:
>
> What tooling what you like to see developed that doesn't exist now?
> I keep reading online that Go has great tooling, but having used it I don't know what people mean when they say that. Likewise, I read that people want D to have great tooling but I also don't know what they mean then either.
>
>> hobby users don't care so much about the tools as they often have their own custom made build tools for D
>
> AFAIK nearly everybody uses dub. What else would you like to see in this area?

Russel has basically answered the question for me. Plugins for IDEs are indispensable, both beginners and experienced programmers appreciate the simplicity of IDEs and plugins. A good asset would be a plugin for Android Studio that compiles and packages your D library automatically.

Apart from that, your vision document is sound because it focuses on practical things that programmers would encounter in their everyday work life.

On Wednesday, 16 October 2019 at 15:39:16 UTC, Paul Backus wrote:
> Consider the following example:
>
> enum isA(T) = __traits(compiles, ...);
> enum isB(T) = __traits(compiles, ...);
> enum isC(T) = __traits(compiles, ...);
>
> enum isAB(T) = isA!T && isB!T;
> enum isAC(T) = isA!T && isC!T;
> enum isBC(T) = isB!T && isC!T;
>
> auto fun(T)(T t) if (isAB!T) { ... }
> auto fun(T)(T t) if (isAC!T && isBC!T) { ... }
>
> C++'s partial ordering for concepts is able to correctly determine that the second overload is more specialized than the first. Your proposed solution that only examines the symbols is not.

Yes it would. But maybe I am not explaining myself well enough. If you were to substitute the symbols and literally count the boolean operators, the fun's would get 1 and 3 respectively. That is what I meant with ast+lookup. Sorry for being so brief.

This is a very alpha idea and far from a solution, it is just that I don't believe it can't be done.

>> Might be a nice project to try to solve with dmd as a library or libdparse, to see if it is more than just an idea.
>
> Overload resolution is handled entirely inside the compiler, so an external tool won't help.

Of course, I understand, but it would suffice as a way to validate the idea. Just give it a bunch of code and it would output the ordering of function overloads with template constraints. See it as a cheap way to validate an idea before mucking in the compiler.

Anyway, I have already talked about it too much.

On Wednesday, 16 October 2019 at 17:40:42 UTC, Atila Neves wrote:
> On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:
>> On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:
>>> [...]
>>
>> I will put this here: https://rawgit.com/wilzbach/state-of-d/master/report.html
>>
>> [...]
>
> Which parts of that survey would you like the vision to include?

First class tuples for me personally.

As a side note, we really need to start discussing the current status of "alias this". Multi "alias this" isn't implemented and walter is now thinking that it is a bad idea in general. He want structs to be implemented via component approach rather then using "alias this". If that were the case then the D language needs to  implement custom implicit conversions for structs/classes as implicit conversions are provided by "alias this". We can implemented it with strict rules to avoid the nightmare scenario that is c++(Opt-in rather then Opt-out).

-Alex

On Wednesday, 16 October 2019 at 18:15:45 UTC, Sebastiaan Koppe wrote:
>> C++'s partial ordering for concepts is able to correctly determine that the second overload is more specialized than the first. Your proposed solution that only examines the symbols is not.
>
> Yes it would. But maybe I am not explaining myself well enough. If you were to substitute the symbols and literally count the boolean operators, the fun's would get 1 and 3 respectively. That is what I meant with ast+lookup. Sorry for being so brief.

In that case, your algorithm will give false positives, which I consider grounds for disqualification. For example:

auto fun(T)(T arg) if (isA!T) { ... }
auto fun(T)(T arg) if (isA!T && isA!T) { ... }

Currently, these overloads are (correctly) considered ambiguous. If we go by symbol counts, however, the second overload would be preferred.

> This is a very alpha idea and far from a solution, it is just that I don't believe it can't be done.

Obviously it can be done: C++ already does it. The question is not *whether* the problem can be solved, but *which* of several possible solutions is the best fit for D.