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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
26 matches
Mail list logo