On Monday, 31 August 2020 at 20:57:02 UTC, claptrap wrote:
> On Monday, 31 August 2020 at 19:33:45 UTC, H. S. Teoh wrote:
>> On Mon, Aug 31, 2020 at 07:11:40PM +0000, IGotD- via Digitalmars-d wrote:
>>> On Monday, 31 August 2020 at 16:34:00 UTC, Paul Backus wrote:
>>>
>> IOW, it's what Andrei has been repeating about adding rather than changing. Add new versions of the language in the same compiler, instead of changing the meaning of the current version of the language.
>
> Could you use a compatibility layer? Say you have a module that is pre safe by default, you could have a component that annotates it so it's safety is explicit and then it can be passed to the new safe by default compiler.
>
> Like the error with ints being truncated on assignment (cant remember what the proper name for it was), you could have a component that just inserts casts where needed, and then it could be passed to the newer compiler.

Yes, this is possible, at least for "normal" code--when you get into stuff like mixins and generated code, it becomes more complicated. At the very least, it is possible to have the compiler print a deprecation warning when it encounters code that would have its default changed by the transition. I actually implemented a version of this for extern(C) functions [1] and used it, along with some Vim macros, to add explicit safety annotations to a bunch of declarations in druntime [2].

[1] https://github.com/dlang/dmd/pull/11176
[2] https://github.com/dlang/druntime/pull/3117

> You wouldn't even need compiler versioning, the module could just declare the specific feature it's not updated to yet, and that would cause it to be run through the compatibility process.. Eg..
>
> version(notSafeByDefault);

This is similar to Adam Ruppe's proposal to have blanket-applied attributes change the *default* for a particular scope without overriding attribute inference for template/auto functions. It's an attractive idea, since it allows code to opt-in to @safe-by-default (as well as other attributes like nothrow-by-default) without breaking compatibility.

I think the main thing stopping it from happening is that nobody's stepped forward to write a DIP for it yet. I expect if someone did, it would get a favorable reception.

On 8/31/20 10:42 AM, IGotD- wrote:
> On Monday, 31 August 2020 at 05:28:06 UTC, Ali wrote:
>>
>> Other than that, I think the biggest challenges are making sure all features fit and work together nicely and marketing, making D more popular grow the community etc ...
> 
> I think developers want stability and not a language that chases for the next compiler technology trend as soon as it pops up.
> 
> Also a good base of nice libraries is just as important as the language itself.

Indeed, I get the impression that a lot of Golang's success especially early on was due to the std library

On 8/31/20 3:33 PM, H. S. Teoh wrote:
> ... one way to move forward is to introduce a language
> versioning mechanism to D, such that each module declares which language
> version it was written in. The compiler would internally have multiple
> versioned components that represent selected "frozen" states of the
> language, which would be selected by this version directive so that it
> retains the old semantics of the language. Ideally, this would allow us
> to retain complete backward compatibility (at least up to the point this
> versioning system was introduced) while allowing newer language versions
> to break things as necessary to implement new features. Since the
> versioning will apply by module, one can incrementally upgrade code to
> newer language versions without being forced to fix everything all at
> once upon installing a newer compiler.

I like this idea and can really give us room to grow.

**This is precisely like Rust editions:**

https://doc.rust-lang.org/book/appendix-05-editions.html

"""
Every two or three years, the Rust team produces a new Rust edition. Each edition brings together the features that have landed into a clear package with fully updated documentation and tooling. New editions ship as part of the usual six-week release process.
...
Each project can opt in to an edition other than the default 2015 edition. Editions can contain incompatible changes, such as including a new keyword that conflicts with identifiers in code. However, unless you opt in to those changes, your code will continue to compile even as you upgrade the Rust compiler version you use.
"""


An entire guide to Rust editions:
https://doc.rust-lang.org/stable/edition-guide/

On Sunday, 30 August 2020 at 17:32:32 UTC, Eljay wrote:
> What is left to do for D 2.x for it to be declared "done" and in stable/bugfix mode only?
>
> [...]

I'm curious to know what EXACTLY CANNOT be done in current D that requires doing a new version.

On Tuesday, 1 September 2020 at 13:36:37 UTC, aberba wrote:
> I'm curious to know what EXACTLY CANNOT be done in current D that requires doing a new version.

It is rather obvious at this point that it is very difficult to gain momentum with the current design. But you see some of the same type of complaints on the Rust forums too (complaints that Rust is too constraining, too complicated, weird etc).

Right now, the best language for targeting WASM would have a chance. Maybe Zig, maybe Rust, probably not Go, Nim or D. Currently C/C++ is perceived as being the best option for WASM, AFAIK.

On Tuesday, 1 September 2020 at 13:36:37 UTC, aberba wrote:
> On Sunday, 30 August 2020 at 17:32:32 UTC, Eljay wrote:
>> What is left to do for D 2.x for it to be declared "done" and in stable/bugfix mode only?
>>
>> [...]
>
> I'm curious to know what EXACTLY CANNOT be done in current D that requires doing a new version.

Alternatively, what language evolutions would admit simpler, performant code?

I think that adding pure type variables would help, a lot.  Type functions, filters, maps, UFCS (typeVar.yourTraitHere), readily composable type libraries, ...  All these things *can* be done today, sort of, with our ever growing zoo of template magic tricks, conventions, and builtins, but there is a simpler and better way forward.

On Sunday, 30 August 2020 at 17:32:32 UTC, Eljay wrote:
> What is left to do for D 2.x for it to be declared "done" and in stable/bugfix mode only?
>
> I haven't seen a Vision/20xxHy for a while.
>
> What features (and breaking changes) are on the horizon for when the next generation D 3.x begins?
>
> [...]
>
> Thoughts?  Plans?  Roadmap?

Once again: I don't see D3 happening. There are plenty of bugs to fix, and we can do it gradually. We are doing it gradually, in fact.

Everyone has their own agenda, but as mentioned by Ali, we need people to do the job. So while I don't know what other people have in mind, here's my TODO list:

1) `in` parameters: Will be in v2.094.0
I started to adapt libraries so everyone can "just" use it as soon as it's released.
If things work fine (no bug), and it has the adoption I hope, then I'll push to have it enabled after 10 to 15 releases (perhaps more). At a cadence of 1 release / 2 months, that puts at release 2.104 in May 2022, or 2.109 in January 2023.

2) `inout`-style attributes for functions accepting delegates: Essentially the invert of DIP1032. I strongly believe that we need a way to have a non-templated function which attributes are dependent on one or more delegate it accepts. This is an essential piece to make OOP and attributes work together. It would also solve so many pain points with `opApply`. It needs a proper DIP and a proper implementation. That's the next language change I plan to tackle once `in` parameters are "done" (aka don't need my attention, not necessarily enabled by default).

3) Moving from Bugzilla to Github: I started working on this, but due to various conflict in schedule / discussions, it was put on hold, and is now in a weird lingering stage. I'd like to resume this, eventually, but it requires a lot of tedious work, so that's not something that will be completed anytime soon (unfortunately).

Those are the main 3 big items I see myself working on for the foreseeable future, aside from the other maintenance work.

----
I left this as a draft for a while, to see where the conversation went. One thing you can check, if you want to see where the language is going, are the `-preview` switches. Next release, `-preview=markdown` is going to be enabled by default. Someone is working on enabling `-preview=dtorfields`. And obviously, the elephant in the room, `-preview=dip1000`.
Aside from that, the DIP queue is also a good source of informations.

On Tuesday, 1 September 2020 at 14:48:19 UTC, Ola Fosheim Grøstad wrote:
>
> It is rather obvious at this point that it is very difficult to gain momentum with the current design.

I didn't quite understand that sentence. What is the problem with the current design that prevents D from gaining momentum?

On Tuesday, 1 September 2020 at 15:17:03 UTC, Mathias LANG wrote:
> On Sunday, 30 August 2020 at 17:32:32 UTC, Eljay wrote:
>> What is left to do for D 2.x for it to be declared "done" and in stable/bugfix mode only?
>>
>> I haven't seen a Vision/20xxHy for a while.
>>
>> What features (and breaking changes) are on the horizon for when the next generation D 3.x begins?
>>
>> [...]
>>
>> Thoughts?  Plans?  Roadmap?
>
> Once again: I don't see D3 happening. There are plenty of bugs to fix, and we can do it gradually. We are doing it gradually, in fact.
Yes.  We're mostly "adding" our way to D3, rather than "changing".

>
> Everyone has their own agenda, but as mentioned by Ali, we need people to do the job. So while I don't know what other people have in mind, here's my TODO list:
>
> 1) `in` parameters: Will be in v2.094.0
> I started to adapt libraries so everyone can "just" use it as soon as it's released.
> If things work fine (no bug), and it has the adoption I hope, then I'll push to have it enabled after 10 to 15 releases (perhaps more). At a cadence of 1 release / 2 months, that puts at release 2.104 in May 2022, or 2.109 in January 2023.

I think this will have a very large positive impact: widely applicable, easily adopted, bug precluding.  Many thanks.

>
> 2) `inout`-style attributes for functions accepting delegates:
...
Improving transparency and control in composition: yes.

>
> 3) Moving from Bugzilla to Github: I started working on this,
...
>
> Those are the main 3 big items I see myself working on for the foreseeable future, aside from the other maintenance work.
>

We all benefit from your well targeted work on the near-frontier Mathias.  Again, many thanks.

On Tuesday, 1 September 2020 at 15:23:10 UTC, IGotD- wrote:
> On Tuesday, 1 September 2020 at 14:48:19 UTC, Ola Fosheim Grøstad wrote:
>>
>> It is rather obvious at this point that it is very difficult to gain momentum with the current design.
>
> I didn't quite understand that sentence. What is the problem with the current design that prevents D from gaining momentum?

Assuming that everything is perfect (in terms of the mechanics of a language) then it seems that programming languages tend to gain momentum when they "appear simple" compared to the alternatives, then they accrue complexities as they sustain that momentum.

When C++ emerged it made structuring larger programs simpler than with C. Complexities was accrued after gaining momentum.

Basically the threshold for picking up a small language is lower if the language does not look like it requires much time investment.

Python looks simple, although it actually can be complicated. Go looks simple etc. Rust claimed to be simpler than C++ (within the explicit memory management paradigme).

D1 had the "looks simple" quality too, but probably aggregated complexity at a stage that was too early.