Re: DLF September 2023 Planning Update
On Wednesday, 15 November 2023 at 21:48:04 UTC, Mike Shah wrote: On Wednesday, 15 November 2023 at 05:27:40 UTC, Mike Parker wrote: On Wednesday, 15 November 2023 at 02:27:42 UTC, Mike Shah wrote: [...] It's just like any other language feature you have to learn. The documentation will be clearly divided by edition. You'll have one section for the base language (the default edition) and one for each subsequent edition. You can jump in an use the default language without caring about editions. Then when you want to learn more, say sumtypes and tuples from edition N, the documentation, tutorials, and example code you see should make it very clear that you need to specify edition N. And the documentation for edition N will explain all the changes that edition makes. [...] Makes sense -- thanks Mike! Looking forward to learning more! I will add that the idea of annotating 'edition' or 'version' is something I am use to doing in glsl (e.g. '#version core 410' goes at the top of the file), so that is pretty easy. For others, I'm reading about Rust editions (https://doc.rust-lang.org/edition-guide/introduction.html) to try to get more education for now. Indeed looks like a win for DLang to adopt something similar. For C++ there was an epoch proposal (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html) as well probably worth skimming for others.
Re: DLF September 2023 Planning Update
On Wednesday, 15 November 2023 at 05:27:40 UTC, Mike Parker wrote: On Wednesday, 15 November 2023 at 02:27:42 UTC, Mike Shah wrote: [...] It's just like any other language feature you have to learn. The documentation will be clearly divided by edition. You'll have one section for the base language (the default edition) and one for each subsequent edition. You can jump in an use the default language without caring about editions. Then when you want to learn more, say sumtypes and tuples from edition N, the documentation, tutorials, and example code you see should make it very clear that you need to specify edition N. And the documentation for edition N will explain all the changes that edition makes. [...] Makes sense -- thanks Mike! Looking forward to learning more!
Re: DLF September 2023 Planning Update
On Wednesday, 15 November 2023 at 11:05:03 UTC, Jonathan M Davis wrote: So, we'll have to see what they actually manage to come up with. I guess this is the only way to understand the idea of how this should work.
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 20:09:53 UTC, Dennis wrote: On Tuesday, 14 November 2023 at 19:13:38 UTC, Steven Schveighoffer wrote: As I understand the current thinking, that is not what D is intending to do. Additional changes don't require a new edition to be enabled, only breaking changes. I expect editions to mostly subtract code, by turning existing deprecations into errors and enabling preview switches like nosharedaccess, dip1000, fixImmutableConv, systemVariables. This sounds like it's not the mechanism being envisioned for modifying phobos or druntime. Looking forward to the full description! -Steve
Re: Beerconf November
On Sunday, 12 November 2023 at 21:12:34 UTC, Sergey wrote: At last beerconf was discussion that last week of the month is always under pressure of deadlines and plans.. There were proposals to postpone it in the middle of the month I must not have been online during that discussion. I'm certainly open to moving it to another weekend, I can drink a beer any time of month ;) I'll set up a poll. I also just realized, this is the weekend after Thanksgiving... But my turkey coma should be over by then. -Steve
Re: DLF September 2023 Planning Update
On Wednesday, November 15, 2023 3:26:27 AM MST Sergey via Digitalmars-d- announce wrote: > On Wednesday, 15 November 2023 at 09:27:53 UTC, Jonathan M Davis > > wrote: > > On Tuesday, November 14, 2023 12:37:29 PM MST Sergey via > > > > Digitalmars-d- announce wrote: > >> +1 to Steven’s approach > >> > >> Idk why DLF don’t like KISS approach :( > > > > Their focus is on allowing existing dub packages to continue to > > compile without any effort whatsoever on the part of anyone > > using them, because the breakage of dub packages over time as > > the language changes has become a serious issue (that's the > > main reason that they started looking at doing editions in the > > first place). > > Maybe I didn't understand the approach. > like let's assume several editions already in place (and we are > in 2030) and the project has several dependencies: > - main code (works with latest version. Latest edition) > - depmain.1 (work only with edition 2022) > - depmain.2 (work only with edition 2023) > > |- dep2.1 (work with editions 2023-2027) > |- dep2.2 (work only with edition 2029) > > So instead of force users to explicitly specify editions in > dub.jsons - DLF propose to use just "dub build" (without any > changes in code of dependency packages and main project) and > somehow each edition should be identified for each package? As I understand it, the language that we have now (or whatever it is when editions are actually added) will be the default edition, and any code wanting to build with a newer edition will have to specify it in the source code. So, existing code will continue to compile how it does now theoretically forever, and new code that gets written and wants to use a newer edition will then specify the edition that it wants to use in each module, so it will continue to compile with that edition forever. Code can of course be updated to use a newer edition, but the edition that it uses will never change unless the code is changed, so it will theoretically all continue to compile the same way that it always has. It does come with the downside of having to slap an attribute on your code to use the latest version of the language, but it means that code will continue to compile the same way that it always has with no effort regardless of what is done with future editions. In contrast, if the default edition is the latest, then code will potentially break as new editions are released, forcing code to be changed over time in order to continue to compile (even if it's just adding an edition attribute to it to force the old behavior), and as we've seen with deprecations, plenty of folks don't want to bother updating their code until they have to (and that's assuming that the code is even still maintained, which can be a real problem with dependencies). The problem could be mitigated by doing stuff with dub (be it by specifying the edition that you want to build a dependency with or by having dub figure it out based on when the code was last updated), but we would have to put in extra work of some kind to then make old code compile again instead of having it just compile forever the same way that it always has. Both approaches have pros and cons. The approach that they currently seem to want to go with is aimed at keeping code compiling with no effort, which should keep dub packages working long term, whereas right now, we have issues with them breaking over time depending on how well they're maintained. And since it's issues with that that are the primary motivators behind editions in the first place (e.g. some of the companies using D depend on packages - potentially many packages - from code.dlang.org, and it's definitely becoming a problem when some of them aren't kept up-to-date with the latest language changes). So, it's not terribly surprising that that's what Walter and Atila would favor. Of course, that does make writing new code more annoying, which is part of why there are objections to it. It also makes it much more likely that a lot of code will just be written for the old version of the language instead of the latest, which could cause issues. So, it's hard to say which approach is better. And of course, regardless of how we deal with specifying editions and which the default is, we still have the question of whether they're actually going to manage to make it sane to mix editions (which you'll inevitably do when a dependency uses a different edition), since features like type introspection (which D code typically uses quite heavily) are likely to make it pretty hard to actually implement. So, we'll have to see what they actually manage to come up with. - Jonathan M Davis
Re: DLF September 2023 Monthly Meeting Summary
On Monday, 13 November 2023 at 16:52:06 UTC, Paul Backus wrote:
On Monday, 13 November 2023 at 16:23:05 UTC, Tim wrote:
The visitor can already be `extern(D)`. Only member functions
overriding those in the base class need to be `extern(C++)`.
Other member functions can then use paratemers, which would be
incompatible with `extern(C++)`.
Wow, it really was that simple all along. Thanks for the tip!
That's not a complete solution. If you template the visitor and
have some member functions that override the extern(C++) base
class methods, then you will still end up with errors if you use
any types that use non-mapable C++ types because of the mangling.
For example:
```d
extern(C++) class DMDVisitor
{
void visit(Expression e) {}
}
class MyVisitor(T) : DMDVisitor
{
T field;
extern(C++) override void visit(Expression e) {} //
troubled line
}
```
Instantiating MyVisitor with a string type will issue an error at
the troubled line because the mangler needs to take into account
the template instance. Since C++ has no dynamic array
correspondent you essentially cannot call MyVisitor.visit from
C++ and therefore the compiler issues an error.
However, if you don't use templated visitors you are fine, you
can just mark your introducing functions/fields as extern(D) and
even if the class is extern(C++) it will work.
Re: DLF September 2023 Planning Update
On Wednesday, 15 November 2023 at 09:27:53 UTC, Jonathan M Davis wrote: On Tuesday, November 14, 2023 12:37:29 PM MST Sergey via Digitalmars-d- announce wrote: +1 to Steven’s approach Idk why DLF don’t like KISS approach :( Their focus is on allowing existing dub packages to continue to compile without any effort whatsoever on the part of anyone using them, because the breakage of dub packages over time as the language changes has become a serious issue (that's the main reason that they started looking at doing editions in the first place). Maybe I didn't understand the approach. like let's assume several editions already in place (and we are in 2030) and the project has several dependencies: - main code (works with latest version. Latest edition) - depmain.1 (work only with edition 2022) - depmain.2 (work only with edition 2023) |- dep2.1 (work with editions 2023-2027) |- dep2.2 (work only with edition 2029) So instead of force users to explicitly specify editions in dub.jsons - DLF propose to use just "dub build" (without any changes in code of dependency packages and main project) and somehow each edition should be identified for each package? Whether that's the right approach is certainly debatable (and personally, I'd rather see something in dub take care of it rather than require that new code slap editions stuff everywhere), but there is a good reason for the approach that they're currently looking at taking. - Jonathan M Davis I think when Grim was ranting about breaking changes and how hard for him fixing it - he meant fixing real code, and I would be quite surprise if for him it will be hard to add into his dub.json/sdl 1 line: "edition" : ["D2022"]
Re: First Beta 2.106.0
On Tuesday, 14 November 2023 at 23:17:32 UTC, Andrey Zherikov wrote: On Thursday, 2 November 2023 at 00:57:23 UTC, Iain Buclaw wrote: Glad to announce the first beta for the 2.106.0 release, ♥ to the 33 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.106.0.html As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team Filed https://issues.dlang.org/show_bug.cgi?id=24246 for ICE Looks like illegal instruction.
Re: DLF September 2023 Planning Update
On Tuesday, November 14, 2023 12:37:29 PM MST Sergey via Digitalmars-d- announce wrote: > +1 to Steven’s approach > > Idk why DLF don’t like KISS approach :( Their focus is on allowing existing dub packages to continue to compile without any effort whatsoever on the part of anyone using them, because the breakage of dub packages over time as the language changes has become a serious issue (that's the main reason that they started looking at doing editions in the first place). Whether that's the right approach is certainly debatable (and personally, I'd rather see something in dub take care of it rather than require that new code slap editions stuff everywhere), but there is a good reason for the approach that they're currently looking at taking. - Jonathan M Davis
Re: DLF September 2023 Planning Update
On Wednesday, 15 November 2023 at 05:27:40 UTC, Mike Parker wrote: If someone misses all of that and tries to use tuples without specifying edition N, the compiler should be able to tell them what the problem is, how to solve it (annotate your module declaration with `@edition(N)`), and provide the URL to the relevant documentation. This is exactly backwards from how most languages today. By default you are working with the current edition and you have to down-select to earlier editions. But if we're really enamored of using the crippled version of the language by default then it is absolutely imperative that edition selection be a command-line option. Here is how it should work IMO. The build system needs to able to specify editions at the package level, but when no package level edition is specified, then you assume current. If you need to down-select to an older edition then the dependency specifier in the project file that I control must set the correct edition. This neatly works around the lack of edition specifier in abandonware without enforcing crippled-by-default behavior that is going to confuse the entire world.
