www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Evolving the D Language

reply Walter Bright <newshound2 digitalmars.com> writes:
As time moves on, the D language has to evolve as well. What do we do with 
obsolete and/or problem-causing, legacy features?

Our answer was deprecation. The deprecation starts out as just a message, which 
can be disabled, or can be set to be errors. The deprecations could last for 
many years, then become errors, but with a "-revert" switch if one still wanted 
to use them.

I thought that was a straightforward approach, giving people many years to 
modernize their code.

I was wrong. I heard you. We're going to have to change course.

We also failed with the `alias this` for classes deprecation, in that we did
not 
offer a reasonable replacment.

We need a new approach to evolving the language (because evolve or die). I'm 
working on the following:

1. continue to evolve the language
2. not deprecate things unless we have to
3. keep legacy code running without complaint as long as we can
4. re-evaluate current deprecations with this in mind
5. resurrect selected legacy constructions that have been removed
6. better documentation for evolving legacy constructions

To that end, we have a new switch: -wo

Currently, the switch does nothing (!). But its intent is, when thrown, to give 
a warning about use of legacy constructions (adding -we will also make them 
errors). The idea is to simply not bother people building legacy projects with 
annoying messages, unless they are pro-actively asking for those messages. This 
way, people can modernize their code at their pace, not at our pace.

But what about constructions that we have learned are unsafe and shouldn't be 
used in  safe code? Code that uses unsafe constructions is not necessarily
buggy 
code. It may be perfectly correct, it's just that the compiler cannot *prove*
it 
is correct. This means the compiler will continue to accept  safe code with 
unsafe legacy constructs. If you need the compiler to do the more thorough
 safe 
checking, -wo will have to be used, and you can scrub out the old constructs as 
you see fit.

Your thoughts and advice are appreciated. Feel free to add this thread your
wish 
lists on legacy feature resurrection that should have priority. Or if you've
got 
a better idea, let us know!

And yes, `alias this` for classes is going back in.
Jul 06 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
I suspect that we kinda have it a little backwards.

Keep it strict by default, but allow more code to pass if desired.

This is how a build manager like dub should operate.

Part of the goal here is to make sure people don't go round using 
undesirable features by accident.

Also we should probably have the ability to turn on only a subset of the 
features based upon version. That way you can only accidentally add 
behavior that you already know about and not have infinite possibilities 
going forward.



And for the record I still want hex strings to come back. They were 
incredibly useful with no good alternatives when we talk about large 
tables of data being described.
Jul 06 2023
next sibling parent reply Hipreme <msnmancini hotmail.com> writes:
On Friday, 7 July 2023 at 03:14:38 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 I suspect that we kinda have it a little backwards.

 Keep it strict by default, but allow more code to pass if 
 desired.

 This is how a build manager like dub should operate.

 Part of the goal here is to make sure people don't go round 
 using undesirable features by accident.

 Also we should probably have the ability to turn on only a 
 subset of the features based upon version. That way you can 
 only accidentally add behavior that you already know about and 
 not have infinite possibilities going forward.



 And for the record I still want hex strings to come back. They 
 were incredibly useful with no good alternatives when we talk 
 about large tables of data being described.


There is 2 views to that side:

1: People doing their project and maintaining only their project.
2: People doing their project that has dub dependencies.


The problem right now, from my POV, is that people such as Grim 
is using dub dependencies. What that generates is that by the 
default functionality being showing the deprecation messages is 
that we need to modify unmaintained 3rd party code. How we use 
3rd party code right now? DUB. The problem is that dub doesn't 
have a flag for keeping 3rd party code shut. So, in MY VIEW, dub 
should be the one to address that problem, not the D compiler 
itself.

One can see here that mostly people that disagreed with Walter's 
proposal is people which maintain all their own code. But that is 
obvious, since we're actively maintaining all of our dependencies 
basically. But thinking on a new user, what happens when they 
don't want to deal with 3rd party code or things feel like just 
out of control? It is not everyone that wants to fork something 
and use the forked version and start maintaining it.


On the `alias this` functionality, I think Walter is correct into 
saying that "we were wrong into deprecate this functionality 
without giving something to replace". `Alias this` is not 
incredible, but we have no reason to simply remove from the 
language without any kind of replacement.


But this is a long standing problem with dub that should be 
fixed: How global flags will behave or even having them: 
modifying `DFLAGS` environment variable is a hassle since it 
involves one command more, and most of the time it is not easily 
portable. Hipreme Engine has solved that problem by having 
something that runs before everything (and controls) , but dub 
itself hasn't solved. A good example of flags is the 
link-defaultlib-shared, -boundscheck and other things that 
changes how the language works somehow.

Warnings and deprecations aren't that different, so, I think dub 
should have a better way to manage 3rd party code. Also, seeing a 
lot of deprecation warnings as default for beginners is quite bad 
since they will be more discouraged to use its library and then 
someone will reinvent the wheel not because they're willing to do 
it for study, but because they will feel that it's NECESSARY.
Jul 07 2023
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
A big problem with compiler switches is that they have to apply to 
everything in a build, or things won't line up. You can't pick and 
choose which module it applies to, even if you could, its going to lead 
to people having a very bad day.

This is another reason why strict by default is the right choice.

If you become strict instead you break peoples code. But if you allow 
obsolete you do not (it could appear anywhere in a build graph).

Either way, I don't think this is 100% there yet.
Jul 07 2023
prev sibling parent harakim <harakim gmail.com> writes:
On Friday, 7 July 2023 at 12:34:50 UTC, Hipreme wrote:

 The problem right now, from my POV, is that people such as Grim 
 is using dub dependencies. What that generates is that by the 
 default functionality being showing the deprecation messages is 
 that we need to modify unmaintained 3rd party code. How we use 
 3rd party code right now? DUB. The problem is that dub doesn't 
 have a flag for keeping 3rd party code shut. So, in MY VIEW, 
 dub should be the one to address that problem, not the D 
 compiler itself.


I don't know how dub would address this problem by itself, but 
this is the number one issue that keeps me from using D as my 
primary personal language. And I agree that it's third party 
libraries that are an issue. I mean I have some old D1 code using 
Tango, but other than that, I do not have issues upgrading my own 
code. I don't like that it breaks, but if it were only my code 
that broke, I would use it as my primary language for personal 
projects.

After some discussion with Adam a few years ago, I heavily 
limited the libraries I use and I don't have this issue nearly as 
much anymore, but what it means is I am less likely to reach for 
D on a project, especially for something like a game where I 
would need third party libraries. And when I'm far more familiar 
with 3 other languages and tool chains, I don't reach for it for 
many of the 1-hour projects either. Although, I did do the timed 
programming course for a new job in D. :D


and Java and, to a lesser extent, C, I wouldn't associate "new 
project in D" and "will take forever" in my mind and I would 
start by trying to make it work in D, like I used to.
Jul 08 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/6/2023 8:14 PM, Richard (Rikki) Andrew Cattermole wrote:

 And for the record I still want hex strings to come back. They were incredibly 
 useful with no good alternatives when we talk about large tables of data being 
 described.


For reference:

https://github.com/dlang/dmd/pull/13773
Jul 07 2023
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote:

 As time moves on, the D language has to evolve as well. What do 
 we do with obsolete and/or problem-causing, legacy features?



As long as the compiler code is not deleted, it can be ensured 
that the `compilation` compiles the `previous code`. It is 
recommended to create a `deprecation` directory to specifically 
collect the `deprecation` function.
Jul 07 2023
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 7 July 2023 at 08:53:17 UTC, zjh wrote:

 As long as the compiler code is not deleted, it can be ensured 
 that the `compilation` compiles the `previous code`. It is 
 recommended to create a `deprecation` directory to specifically 
 collect the `deprecation` function.



Each user only needs a `features switch` file with their own used 
`features`, and when the `compiler`compiles, these `features 
switches`are used to compile code. If there is `deprecated` 
features, the `deprecation` directory function is called. This 
way, like `C++`, as long as I do not remove the ` deprecation` 
feature code, I can ensure that the previous code can be 
`compiled`!
Jul 07 2023
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 7 July 2023 at 08:59:19 UTC, zjh wrote:

 
 Each user only needs a `features switch` file with their own 
 used `features`,



  Each user has a `feature` file, and if they publish a project, 
they put the `file` into the`project`. This is like the 
`configuration` of `vim`, and users can use the `features` 
according to their `own needs`.
Jul 07 2023
parent zjh <fqbqrr 163.com> writes:
On Friday, 7 July 2023 at 09:07:28 UTC, zjh wrote:
This is like the

 `configuration` of `vim`.


In fact, there is a ready-made tool called `sc.ini` that can 
completely extend this file to become a gathering place for more 
configuration files for `d` users.
Of course, you can also use the `d `language as 
the`configuration` language. This way, users can customize a 
series of configurations specifically for their own `d` language! 
I use `d language`to configure `d language`.
Jul 07 2023
prev sibling next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote:

 As time moves on, the D language has to evolve as well. What do 
 we do with obsolete and/or problem-causing, legacy features?

 [...]


I respectfully disagree, and prefer to keep going on with the 
current deprecation and cleanup policy: Scott Meyers' DConf 2014 
keynote all the way down.

On the other side, there's no problem at all in resurrect dead 
features, when living without them proved to be a pain (I agree 
with Rikki, hex strings).

/Paolo
Jul 07 2023
parent reply Guillaume Piolat <first.last spam.org> writes:
On Friday, 7 July 2023 at 09:35:14 UTC, Paolo Invernizzi wrote:

 I respectfully disagree, and prefer to keep going on with the 
 current deprecation and cleanup policy: Scott Meyers' DConf 
 2014 keynote all the way down.


+1

I've always agreed with the deprecation in the end, even complex 
numbers.
alias this was a relatively bad idea, even if an iconic feature.
I don't remember people from outside the community being 
impressed by alias this.
We have the right to backtrack on bad ideas instead of keeping 
them forever.
The __traits changed feature was aout fixing an incorrect 
behaviour. It took 10 min to fix.
The current deprecation system is very good.
Jul 07 2023
next sibling parent reply Nick Treleaven <nick geany.org> writes:
On Friday, 7 July 2023 at 10:45:33 UTC, Guillaume Piolat wrote:

 alias this was a relatively bad idea, even if an iconic feature.
 I don't remember people from outside the community being 
 impressed by alias this.


There was no way to rewrite the code without breaking dependent 
code. That should not happen with a routine compiler release.


 We have the right to backtrack on bad ideas instead of keeping 
 them forever.


Marking a feature as obsolete doesn't mean it has to be supported 
forever. Presumably at some point support will be dropped. 
Possibly obsolete features could become deprecations before they 
are actually removed.


 The current deprecation system is very good.


For something like alias this in classes, making it obsolete 
instead of deprecated signals that the feature won't be removed 
in 20 months (based on a 2-month release cycle, 10 release 
deprecation cycle as standard).
Jul 07 2023
parent reply Guillaume Piolat <first.last spam.org> writes:
On Friday, 7 July 2023 at 13:01:53 UTC, Nick Treleaven wrote:

 Possibly obsolete features could become deprecations before 
 they are actually removed.


It just seems to me, instead of complaining when features become 
deprecated, people will complain when obsolete feature becomes 
deprecated and they see the message. The proposal here is that 
they see the message later. In the meantime, nothing will prevent 
people from using the obsolete feature all over.
Jul 07 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/7/2023 7:56 AM, Guillaume Piolat wrote:

 It just seems to me, instead of complaining when features become deprecated, 
 people will complain when obsolete feature becomes deprecated and they see the 
 message. The proposal here is that they see the message later. In the
meantime, 
 nothing will prevent people from using the obsolete feature all over.


The problem has a lot to do with people wanting to use 3rd party libraries, and 
it being impractical to upgrade those libraries when the maintainer of those 
libraries is no longer active. If a user's project depends on several such 
libraries, it places an undue burden on the user.
Jul 07 2023
parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 7 July 2023 at 22:41:38 UTC, Walter Bright wrote:

 The problem has a lot to do with people wanting to use 3rd 
 party libraries, and it being impractical to upgrade those 
 libraries when the maintainer of those libraries is no longer 
 active. If a user's project depends on several such libraries, 
 it places an undue burden on the user.


The third party import is the biggest pain, and compiler 
versions/deprecations add to it. As another mentioned it is sort 
of a dub problem.

As a user of the third party library I want my code strict, but I 
just want the third party to build as it was written. This has 
two main implication, does the compiler I'm using even know about 
the features the library uses, and if the library author 
instructed the compiler to be strict (I don't care)

If the library is built with a newer compiler version their isn't 
much to be done but upgrade the compiler. This has the 
implications where I would now want to compile my code without 
strictness (hopefully for a short period).

If the compiler has removed features then the library can't be 
built. This is were keeping functionality is beneficial.

If the compiler depricates functionality then I don't want to 
hear about. Though it would be good to know "library x is using 
deprecated functionality". This is where the compiler and dub 
need to work together. Dub can build my code with strict error 
and the the compiler provides a flag dub uses to build the third 
party libraries.
Jul 08 2023
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 7 July 2023 at 10:45:33 UTC, Guillaume Piolat wrote:

 On Friday, 7 July 2023 at 09:35:14 UTC, Paolo Invernizzi wrote:

 I respectfully disagree, and prefer to keep going on with the 
 current deprecation and cleanup policy: Scott Meyers' DConf 
 2014 keynote all the way down.


 +1

 I've always agreed with the deprecation in the end, even 
 complex numbers.
 alias this was a relatively bad idea, even if an iconic feature.
 I don't remember people from outside the community being 
 impressed by alias this.
 We have the right to backtrack on bad ideas instead of keeping 
 them forever.
 [snip]


The question is whether there is a migration path. If they 
removed functionality that didn't have a good foundation and put 
it on one with a better foundation, then I think people would 
have been ok (like removing Complex numbers was annoying, but 
std.complex exists or you can write your own).

The current approach had a lot going for it. I'm sympathetic to 
those who favor being strict by default, but I don't feel 
strongly as I'm not really sure what I think about Hipreme's 
comment about how this all interacts with dependencies. If the 
new switches could turn deprecation errors into warnings or hide 
depreciation errors/warnings, then that might be a good 
complement to the revert switch (revert with a version number is 
also an interesting idea).
Jul 07 2023
prev sibling next sibling parent Olivier Pisano <olivier.pisano laposte.net> writes:
On Friday, 7 July 2023 at 10:45:33 UTC, Guillaume Piolat wrote:

 On Friday, 7 July 2023 at 09:35:14 UTC, Paolo Invernizzi wrote:

 I respectfully disagree, and prefer to keep going on with the 
 current deprecation and cleanup policy: Scott Meyers' DConf 
 2014 keynote all the way down.


 +1

 I've always agreed with the deprecation in the end, even 
 complex numbers.
 alias this was a relatively bad idea, even if an iconic feature.
 I don't remember people from outside the community being 
 impressed by alias this.
 We have the right to backtrack on bad ideas instead of keeping 
 them forever.
 The __traits changed feature was aout fixing an incorrect 
 behaviour. It took 10 min to fix.
 The current deprecation system is very good.


I agree with these two messages.
Jul 08 2023
prev sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Friday, 7 July 2023 at 10:45:33 UTC, Guillaume Piolat wrote:


 I don't remember people from outside the community being 
 impressed by alias this.
 We have the right to backtrack on bad ideas instead of keeping 
 them forever.


I don't know why anybody should be impressed, but Zig and Jai, 
the two closest competitors of D, both have a generalized version 
of 'alias this' ('usingnamespace' and 'using', respectively).
Jul 08 2023
prev sibling next sibling parent reply IchorDev <zxinsworld gmail.com> writes:
On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote:

 As time moves on, the D language has to evolve as well. What do 
 we do with obsolete and/or problem-causing, legacy features?

 Our answer was deprecation. The deprecation starts out as just 
 a message, which can be disabled, or can be set to be errors. 
 The deprecations could last for many years, then become errors, 
 but with a "-revert" switch if one still wanted to use them.

 I thought that was a straightforward approach, giving people 
 many years to modernize their code.

 I was wrong. I heard you. We're going to have to change course.

 [...]


This is an interesting decision indeed. However, definitely I 
agree with Rikki that it should be opt-in, rather than opt-out.


 Your thoughts and advice are appreciated. Feel free to add this 
 thread your wish lists on legacy feature resurrection that 
 should have priority. Or if you've got a better idea, let us 
 know!


Hexstring literals, complex and imaginary floating point types & 
the corresponding literals, built-in 128-bit integer types, and 
octal literals, I think could all be added back to D without 
causing much detriment to D users who don't want to use them. For 
people who do use them, they're very useful to have.
I'm not sure how open you are to tweaking legacy features 
slightly, but here are some suggestions in case that's on the 
table:
1. I think adapting `std.int128.Int128` to make `cent`/`ucent` 
functional for the sake of simpler BetterC code would be really 
lovely. Much nicer than having to create custom wrappers over 
`core.int128.Cent`...
2. Ideally octal literals would have a better syntax. (e.g. 
"0o123")
Jul 07 2023
parent reply Nick Treleaven <nick geany.org> writes:
On Friday, 7 July 2023 at 10:57:57 UTC, IchorDev wrote:

 Hexstring literals,


They were first deprecated on Mar 01, 2018:
https://dlang.org/changelog/2.079.0.html#hexstrings

And removed in 2.086, so it's probably unlikely that any 
maintained code is using them.


 complex and imaginary floating point types & the corresponding 
 literals,


Deprecated in 2.097, maybe a good candidate to obsolete instead.


 built-in 128-bit integer types,


cent and ucent are already an error as of 2.100. Were they even 
implemented?


 and octal literals, I think could all be added back to D 
 without causing much detriment to D users who don't want to use 
 them.


...

 2. Ideally octal literals would have a better syntax. (e.g. 
 "0o123")


Changing the syntax just for an obsolete feature would send the 
wrong message. People rarely use octal so it doesn't need to be 
in the language, library is enough. The C syntax is indeed bug 
prone - leading zero.
Jul 07 2023
parent reply IchorDev <zxinsworld gmail.com> writes:
On Friday, 7 July 2023 at 13:19:51 UTC, Nick Treleaven wrote:

 Changing the syntax just for an obsolete feature would send the 
 wrong message.
 [...]
 cent and ucent are already an error as of 2.100. Were they even 
 implemented?


Clearly you're not looking at this the same way as me, [or 
Walter](https://github.com/dlang/dmd/pull/15393).
Fixing old code isn't the only upside to resurrecting old 
features.

First thing, I think all languages should support binary, octal, 
decimal and hexadecimal literals as a baseline. Octal is probably 
the least important of them, but can still be plenty useful in 
its own right. You technically don't need *any* numerical 
literals at all in D, you could make all of them with 
string-to-number templates. You could take such an approach to 
just about everything in D, actually! On the other hand, people 
working on low-level Linux code might be pretty appalled to find 
out that they can't simply use octal literals to represent file 
permissions in D.

Second, I think re-examining and sometimes resurrecting features 
that were removed from D, no matter how long ago, is important.
Think about it this way, the only reason D doesn't have octal 
literals right now is because when it did have octal literals the 
syntax was ambiguous. The solution at the time was removing them 
from the language, but had their syntax been modified at the time 
then they wouldn't have been ambiguous. Who says it's too late?

There are a few D features that were poorly implemented (or not 
implemented at all), and then simply removed instead of being 
fully reconsidered. You might say that for many, they were indeed 
reconsidered, and then added to Phobos instead. Now some of these 
features pre-date BetterC, of course, but I am a regular BetterC 
user. A feature being moved to Phobos translates to "you don't 
get to use this in most of your code anymore" for me. I'm not a 
user of complex or imaginary types, but I don't see why they 
needed to be removed from D, were they a huge burden to maintain 
compared to being in Phobos?

TL;DR I think we should be more lenient about leaving features in 
the language if they aren't in the way, and consider ways of 
modifying them rather than removing them from the language if 
they get in the way.
Jul 09 2023
next sibling parent IchorDev <zxinsworld gmail.com> writes:
On Sunday, 9 July 2023 at 18:51:01 UTC, IchorDev wrote:

 [...]


I felt that I should also clarify that there are some features 
that *should* stay dead, for our benefit. I figured I'd name a 
few.
1. Bugs that some people treated like features. There's a few 
listed among D's deprecated features.
2. `body`—find-and-replace is enough to update it, and `body` 
shouldn't be a keyword.
3. C-style function pointers. They are absolutely horrid; so hard 
to read that it hurts.
4. Escape-string literals seem to have been designed to confuse 
people, much like
5. implicit string concatenation.
6. De-referencing arrays with `*`.
7. Comma expression results. Tuples & deconstruction instead 
would be nice!

Most of these changes don't really prevent you from doing things 
you could previously do with the base language (like removing 
class `alias this`), they syntax clean-up that you can mostly 
update to with a rudimentary regex or a bit of manual 
error-pecking.

P.S. "error-pecking" as in "build, try to fix any compiler 
errors, rinse, repeat".
Jul 09 2023
prev sibling parent Nick Treleaven <nick geany.org> writes:
On Sunday, 9 July 2023 at 18:51:01 UTC, IchorDev wrote:

 On Friday, 7 July 2023 at 13:19:51 UTC, Nick Treleaven wrote:

 Changing the syntax just for an obsolete feature would send 
 the wrong message.
 [...]
 cent and ucent are already an error as of 2.100. Were they 
 even implemented?


 Clearly you're not looking at this the same way as me, [or 
 Walter](https://github.com/dlang/dmd/pull/15393).
 Fixing old code isn't the only upside to resurrecting old 
 features.


I thought Walter was asking for features that should be changed 
from deprecated to obsolete, it seems I was wrong.


 First thing, I think all languages should support binary, 
 octal, decimal and hexadecimal literals as a baseline. Octal is 
 probably the least important of them, but can still be plenty 
 useful in its own right.


Generally programmers can count in binary and decimal, hex 
somewhat. Not octal.


 You technically don't need *any* numerical literals at all in 
 D, you could make all of them with string-to-number templates. 
 You could take such an approach to just about everything in D, 
 actually! On the other hand, people working on low-level Linux 
 code might be pretty appalled to find out that they can't 
 simply use octal literals to represent file permissions in D.


Maybe because they're used to working in languages that don't 
have D's CTFE abilities. Octals are still rare. There are other 
literals, not all literals can be supported in the language. So 
the better solution for less common literals is to embrace the 
library pattern and dogfood it. C++ has user-defined literal 
support. D doesn't need that.

...

 There are a few D features that were poorly implemented (or not 
 implemented at all), and then simply removed instead of being 
 fully reconsidered. You might say that for many, they were 
 indeed reconsidered, and then added to Phobos instead. Now some 
 of these features pre-date BetterC, of course, but I am a 
 regular BetterC user. A feature being moved to Phobos 
 translates to "you don't get to use this in most of your code 
 anymore" for me.


`octal` could have been added to druntime, or you can copy the 
code. For betterC there's probably quite a lot of stuff in Phobos 
that works with betterC, so that is a general problem.


 I'm not a user of complex or imaginary types, but I don't see 
 why they needed to be removed from D, were they a huge burden 
 to maintain compared to being in Phobos?


It depends whether you value language simplification and 
dogfooding.
Jul 12 2023
prev sibling next sibling parent Johan <j j.nl> writes:
On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote:

 To that end, we have a new switch: -wo


Isn't that just another "deprecation" switch?

I'm now thinking that deprecations in general are causing us 
headaches, but the all-or-nothing approach. You either turn all 
warnings/deprecations into errors (i.e. keeping your code clean, 
preventing people newly introducing deprecated/bad constructs), 
or none of them.
If there is a way to selectively enable/disable 
warnings/deprecations, then the problem goes away. Because if a 
newly introduced deprecation is causing trouble, you can 
selectively disable that one and continue development while being 
protected from introduction of old deprecations.

I added this in the past but it was slain :((
https://github.com/dlang/dmd/pull/5592

-Johan
Jul 07 2023
prev sibling next sibling parent Doigt <labog outlook.com> writes:
On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote:

 As time moves on, the D language has to evolve as well. What do 
 we do with obsolete and/or problem-causing, legacy features?

 [...]


Yes, I agree with all of this. Thank you.
Jul 07 2023
prev sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote:

 1. continue to evolve the language


I'm super excited about this!

- Tagged Union? :D

- Pattern Matching? :D ()

- Built-in Tuple with deconstructing? :D
Jul 07 2023