On Tuesday, 15 October 2019 at 14:53:47 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 15 October 2019 at 13:34:46 UTC, jmh530 wrote:
>> In this thread [1], Ola makes the argument that std.concurrency is not actor-based because they are not independent.
>
> D most certainly isn't actor based, although you can provide libraries that enable actor-like modelling. It is not unreasonable to say such in a blog post where people should interpret things less formally.
>
> What I pointed out was that it is unreasonable to claim it in the online documentation.
>
> Fault tolerance is a key aspects of actors. For that you need independence between actors. D can never provide that with a library.

For those interested:

https://en.wikipedia.org/wiki/Actor_model#Fundamental_concepts

D can not provide any of these qualities.

The term «actor» is more loosely used than «the actor model» though, so you can have «actors» even if you don't implement «the actor model».

On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:
> This thread is for general feedback and discussion regarding Átila's blog post on his vision for D's future.
>
> https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/

If you pardon me making yet another "D need this" post:

(This is not a criticism about the vision but more an observation of the D vision until now)

There are no "community" points in the above vision but mostly language points, so I think it continues in a not-that-fruitful direction, a sort of escapism.

Language nowadays are co-designed along with the community ; this community's task is to create the open-source ecosystem that will lure users into using the language. Of course, it's up to the community to self-organize, however a bit of topdown organizing/funneling users can always help.

Availability of open source libraries are the #1 reason people use a new programming language.

But the problem is that our ecosystem of libraries, while it exists and has solution for most everything, interoperates pretty badly. It is not maintained enough (or for the latest compilers only), and/or isn't generally dependable.

Perhaps because of our native backgrounds, we are still quite bad at sharing code. Nothing to do with what happens in the NPM ecosystem. We need to go out of our way to create high-quality, dependable software artifacts with shared maintenance that can be reused.

This means, practically-speaking:
- fixed DUB rankings
- fixed DUB search
- gamification of HQ library creation
- focus on DUB user experience (the one gateway to compiler cmdline)
- cooperation over multiple-solutions
- better documentation as a way to get the people to do the above points

I'm just not excited about language-level features

On Tuesday, 15 October 2019 at 13:55:28 UTC, SrMordred wrote:
> I Love to see more concrete words about future D.
> Keep the good work!
>
> also, waiting for the nicer traits api:
>
> //D
> const isAddable = __traits(compiles, (T t) { return t + t; });
> //C++20 concepts
> concept isAddable = requires (T x) { x + x; };
>
> Losing to C++ is unacceptable ;)

Meh:

//C++20 concepts
concept isAddable = requires (T x) { x + x; };

// D
enum isAddable(T) = is(typeof((T x) => x + x));


We lose by one character ;)

On Tuesday, 15 October 2019 at 15:05:52 UTC, Meta wrote:
> On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:
>> This thread is for general feedback and discussion regarding Átila's blog post on his vision for D's future.
>>
>> https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/
>

> I'm curious, is Atila's work on this building on Andrei's? I remember him talking about his work on a reflection library at a recent DConf (I think it was last year's).

Yes, I'm stealing Andrei's idea. I'm currently working on said reflection library.

> It's a real pain having to stick a `.format(OneIndexedArray.stringof, store.length, i)` at the end of the message.

I suggest using `std.conv.text` instead. For one liners it's (IMHO) nearly the same as string interpolation. I think string interpolation only comes into its own with multi-line strings, which is common in D because of string mixins and q{}.

> pragma(msg) get's this right, presumably because it's a compile time-only construct.

std.conv.text works exactly the same way.

On Tuesday, 15 October 2019 at 16:16:24 UTC, Guillaume Piolat wrote:
> On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:
>> [...]
>
> If you pardon me making yet another "D need this" post:
>
> (This is not a criticism about the vision but more an observation of the D vision until now)
>
> [...]

These are very good points. Thanks for bringing them up!

On Tuesday, 15 October 2019 at 16:22:22 UTC, Atila Neves wrote:
> I suggest using `std.conv.text` instead. For one liners it's (IMHO) nearly the same as string interpolation. I think string interpolation only comes into its own with multi-line strings, which is common in D because of string mixins and q{}.

I find declaration names to be the most common place to actually concatenate strings in well-written code... and really, interpolation wouldn't help that much compared to `}~VAR~q{`...

On Tuesday, 15 October 2019 at 14:38:41 UTC, H. S. Teoh wrote:
> On Tue, Oct 15, 2019 at 01:09:15PM +0000, Mike Parker via Digitalmars-d wrote:
>> This thread is for general feedback and discussion regarding Átila's blog post on his vision for D's future.
>> 
>> https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/
>
> @safe by default sounds like a VERY good idea. Can't wait to see when we start transitioning! (Though, I'm not holding my breath on it atm -- I realize there's a lot to be done before this will be possible.)
>
> Making D the default implementation language: this sounds a bit general. What exactly does this mean, and what exactly does it entail?  Is this pushing for better marketing ("hey world, let's use D as the default implementation language"), or are we talking about something on the implementation side here?

I mean "Write once (in D), wrap everywhere". No need for an IDL,
no need for translating, just generalise autowrap as it exists now
to make the (hopefully high-performant) D implementation be callable
by C, C#, Java, Python, Julia, ...

I'm close to be able to write a blog post on how the easiest way to call C code from Python right now is D. Run dpp -> use autowrap -> no code written and everything is now available from Python. Or Excel, C#, ...


> Interop with C++: while I applaud this goal, I'm not sure how exactly we're going to pull this off,

Me neither. But we're in a better position than anyone else to do it, and if it happens to work in enough use cases we'll have a competitive advantage.

> C++ programmers expect to be able to cast away const without invoking UB,

Which is only *not* UB if the data wasn't const to begin with. Otherwise...

> Anyway, as for pet peeves / pet features: I'd like to propose having a plan for Phobos v2 as Andrei has mentioned once.  There are some design decisions in Phobos that are hard to reverse now, like autodecoding, the whole shebang about .save in std.range, etc.. We *might* be able to pull off removing autodecoding as a gradual transition, but that's impossible for the range API since just about *everything* in Phobos uses it. The only possible way I see is std.v2.

I've thought about Phobos v2 but haven't been able to conclude anything yet.

On Tuesday, 15 October 2019 at 16:16:24 UTC, Guillaume Piolat wrote:
> - fixed DUB rankings

but but my stuff has been consistently #2 the last few weeks

clearly the rankings are already fixed :P

On Tuesday, 15 October 2019 at 16:22:22 UTC, Atila Neves wrote:
> I suggest using `std.conv.text` instead. For one liners it's (IMHO) nearly the same as string interpolation. I think string interpolation only comes into its own with multi-line strings, which is common in D because of string mixins and q{}.
>
>> pragma(msg) get's this right, presumably because it's a compile time-only construct.
>
> std.conv.text works exactly the same way.

I know, and I do like std.conv.text, but you can't put it in trailing/UFCS position with multiple arguments:

//doesn't work
in (a < b, ("argument must be greater than argument b (a: ", a, ", b: ", b, ")").text())

And it causes me great pain to write `text("a message ", with " lots of ", interleaved, " ", arguments)`

Which is why I prefer to use format (not to mention the comma soup making the string much more busy visually with text()).

With interpolated strings, presumably this could be allowed?

i"argument must be greater than argument b (a: $a, b: $b)".text()

Which I could live with, but would still prefer it if even the text() could be omitted.

On Tuesday, 15 October 2019 at 16:17:57 UTC, Atila Neves wrote:
> Meh:
>
> //C++20 concepts
> concept isAddable = requires (T x) { x + x; };
>
> // D
> enum isAddable(T) = is(typeof((T x) => x + x));
>
>
> We lose by one character ;)

The one advantage C++ concepts have over D's template predicates is that they're transparent to the compiler. As a result, the compiler is able to determine a partial order on template constraints [1], and use that order to resolve overloads (just like D does with regular function overloads [2]). D can't do this, so we're stuck writing awkward things like this:

auto myAlgorithm(R)(R r) if (isInputRange!R && !isRandomAccessRange!R) { ... }
auto myAlgorithm(R)(R r) if (isRandomAccessRange!R) { ... }

...or this:

auto myAlgorithm(R)(R r) if (isInputRange!R)
{
    static if (isRandomAccessRange!R)
        return myRandomAccessRangeImpl(r);
    else
        return myInputRangeImpl(r);
}

...in order to make our constraints both disjoint and exhaustive.

[1] https://en.cppreference.com/w/cpp/language/constraints#Partial_ordering_of_constraints
[2] https://digitalmars.com/articles/b20.html