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/

On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:
> https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/

"meaning that today, D isn’t memory safe."

Why exactly isn't it? I thought that with -dip1000, D does not allow memory corruption in @safe code, except for implementation bugs and wrong @trusted code. The currently proposed  borrowing/ownership related DIPs are just to make more non-GC memory styles @safe as far as I know, but I could be wrong.

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/

String interpolation! Love the note on mixin strings. Code written in that way should look similar to Lisp macros? It hadn't occurred to me until I saw that that string interpolation for q{} is basically equivalent to quasiquoting.

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 glad to see this. I liked the old Vision documents.

One quibble where he says:

"We’re mostly there—using the actor model eliminates a lot of problems that would otherwise naturally occur. We need to finalize shared and make everything @safe as well."

On the make everything @safe, you might want to make that clearer. Do you mean make everything in phobos @safe? Or something else?

Also, the comment about using the actor model...I don't think the documentation states that D is using the actor model...

In this thread [1], Ola makes the argument that std.concurrency is not actor-based because they are not independent. I have no idea if that's true or not...


[1] https://forum.dlang.org/post/pbnovrvmsifgvwquttnp@forum.dlang.org

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/

* Memory safety
* Make D the default implementation language
* Second to none reflection.
* Fast development times.

my favorite points out of all the good points! The concurrency goal sounds a bit vague but otherwise I am looking forward to how D will develop with these visions in mind. I definitely think they will all be improvements which will greatly improve our lifes using D.

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 ;)

Exciting vision!

My favorites are

* Memory safety combined with Safe and easy concurrency: Add a way to globally use RC instead of GC for high-concurrency situations (to mitigate stop-the-world issues) would be awesome
* Fast development times: Apart from unittests, an interpreter could greatly boost D's usage in data science (think Jupyter Notebook) by leveraging the excellent mir-libraries
* String interpolation: Really handy with string mixins!
* Make D the default implementation language: This is both bold vision.. when thinking of widespread adoption - yet improvements regarding the other visions should greatly help

Cheers!

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?

Interop with C++: while I applaud this goal, I'm not sure how exactly we're going to pull this off, seeing as there are some fundamental incompatibilities with C++ like transitive const, no Koenig lookups, a different (albeit mostly compatible) templating system, etc.. Back in the day C++ started off as essentially "C with classes", meaning existing C code was practically 100% compilable as C++ (of course, there are some subtle differences, but for the most part this is true). But with D, some syntax like templates have a fundamentally different syntax, and you're not gonna be able to just compile non-trivial C++ code as D without endless pages of syntax errors. This, of course, is merely at the syntactic level. But the lack of transitive const is a deeper problem that isn't going to be easy to solve: C++ programmers expect to be able to cast away const without invoking UB, and in D you just can't do that without getting into UB land.

//

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.

Plus, I'd like to see this not just as a one-off thing, but an ongoing development and refinement of D as time goes on.  In the realm of natural languages, languages are a living, dynamic thing that changes and develops over time, adapting to the circumstances it's used in; it's not a static thing that stays fixed forever. (A static natural language is a dead one -- like Latin.)  IMO a programming language also has to be constantly adapting and developing to fit contemporary needs, and one should not expect it to stay static forever.  In more practical terms, this means D needs to have *official mechanisms* in place for retiring old features (not necessarily get rid of them -- nobody wants to be rewriting legacy code every 5 years -- we can keep old features in the back closet as long as they don't interfere with new ones) and introducing new ones. std.v2 is one step in this direction, and I'd like to see a consistent, workable scheme that would allow for std.v3, std.v4, etc., in the distant future.

There is already the current deprecation process for relatively small, gradual transitions; but I'd like to see a process for larger-scale (probably longer-term) changes like std.v2, reworking the range API, etc..


T

-- 
The right half of the brain controls the left half of the body. This means that only left-handed people are in their right mind. -- Manoj Srivastava

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.

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/

"Instead of disparate ways of getting things done with fragmented APIs (__traits, std.traits, custom code), I’d like for there to be a library that centralizes all reflection needs with a great API."

Yes, 100% agreed. Another benefit of having one unified API is that it's easier to paper over the weird differences between various methods of doing reflection.

Ex:

is(typeof({ return x + x; })) vs __traits(compiles, { return x + x; })

__traits(identifier, x) vs. x.stringof (x.stringof will fail to compile if x is a function with at least 1 parameter, but __traits(identifier) works)

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

"String interpolation"

I've been finding a lot of places in my code where string interpolation would make it much more readable. It would be nice to be able to use them in invariants, in contracts, out contracts, and assert statements, e.g.:

struct OneIndexedArray(T)
{
    T[] store;

    T opIndex(size_t i)
    in (i > 0, "Index $i is out of range for $(OneIndexedArray.stringof)")
    in (i < store.length,
         "Index is out of range for $(OneIndexedArray.stringof) (length: $(store.length), index: $i")
    {
        ...
    }
}

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

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