Re: Evolving the D Language
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.
Re: Evolving the D Language
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".
Re: Evolving the D Language
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.
Re: Evolving the D Language
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 In short, if I could count on libraries the same as I do in C# 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.
Re: Evolving the D Language
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.
Re: Evolving the D Language
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).
Re: Evolving the D Language
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.
Re: Evolving the D Language
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
Re: Evolving the D Language
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
Re: Evolving the D Language
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.
Re: Evolving the D Language
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.
Re: Evolving the D Language
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).
Re: Evolving the D Language
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.
Re: Evolving the D Language
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
Re: Evolving the D Language
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.
Re: Evolving the D Language
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).
Re: Evolving the D Language
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.
Re: Evolving the D Language
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.
Re: Evolving the D Language
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")
Re: Evolving the D Language
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`.
Re: Evolving the D Language
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.
Re: Evolving the D Language
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
Re: Evolving the D Language
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`.
Re: Evolving the D Language
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`!
Re: Evolving the D Language
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.
Re: Evolving the D Language
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.
