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: DScanner v0.16.0-beta.1 - looking for IDE dev feedback
On Sunday, 9 July 2023 at 07:54:38 UTC, Christian Köstlin wrote: On 08.07.23 23:59, WebFreak001 wrote: [...] Sounds to good to be true, will give it a try for sure!!! Thanks a lot. Kind regards, Christian thanks, feel free to leave feedback about the CLI and fixes for existing or new diagnostics you would like to see. I just fixed a bug in the CLI that you reported and with the latest version it should work again (CI tested now): https://github.com/dlang-community/D-Scanner/releases/tag/v0.16.0-beta.3
Re: DScanner v0.16.0-beta.1 - looking for IDE dev feedback
On 08.07.23 23:59, WebFreak001 wrote: https://github.com/dlang-community/D-Scanner/releases/tag/v0.16.0-beta.1 ## For IDE devs: the new D-Scanner version comes with a major new improvement: automatic fix suggestions for diagnostics. As IDE dev you can use the existing `--report` functionality to get JSON parsable output for the issues, along with new information such as start/end byte indices. Then when the user wants to query auto-fixes for any given issue (or just in general at any location in the file), use `dscanner --resolveMessage b512 file.d` to list the resolved auto-fixes at the given location. See the README.md for more information. Looking for feedback on the API and if you need any changes. Additionally this API is usable with D-Scanner as a library as well. ## For users: `dscanner fix source/` can be used to interactively auto-fix all issues inside the source/ directory that have available autmoatic fixes. Sounds to good to be true, will give it a try for sure!!! Thanks a lot. Kind regards, Christian
Re: DScanner v0.16.0-beta.1 - looking for IDE dev feedback
On Saturday, 8 July 2023 at 21:59:53 UTC, WebFreak001 wrote: [...] https://github.com/dlang-community/D-Scanner/releases/tag/v0.16.0-beta.2 updated API in v0.16.0-beta.2: `--report` includes all auto-fixes that don't need any resolving now, as well as the names for the to-be-resolved auto-fixes. This way you can show the user that actions are available before trying to query them. (although in the future new classes of auto-fixes could be introduced that are not tied to diagnostics. The API isn't built for this right now though and isn't expected in the near future)
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.
