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 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 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 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 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 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 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 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
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 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
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: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, 30 June 2023 at 16:14:48 UTC, jmh530 wrote:
On Thursday, 29 June 2023 at 23:51:44 UTC, bachmeier wrote:
[snip]
Glad you're continuing to do work on this front. There's a lot
of great material explaining things, which is always good.
It would be cool to have another version of
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 20:33:08 UTC, bachmeier wrote:
[snip]
I was wrong. They added custom allocators a while back, but
didn't tell anyone.
Actually, what I said before is technically correct. The SEXP
struct itself still has to be allocated by R and managed by the
R garbage collector.
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/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 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
20 matches
Mail list logo
