DScanner v0.16.0-beta.1 - looking for IDE dev feedback
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.
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.
