Feedback on Átila's Vision for D

[Atila Neves]

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.