Re: D Language Quarterly Meeting Summary for January 2021
On Tuesday, 25 January 2022 at 00:08:54 UTC, H. S. Teoh wrote: This may work for x86, but does it work for other platforms? If not, it won't fly on LDC/GDC. I don't think there's anything wrong with d having its own ABI. But, I checked arm and riscv: both of their c calling conventions have scratch registers not used for parameter-passing.
Re: D Language Quarterly Meeting Summary for January 2021
On Mon, Jan 24, 2022 at 10:56:57PM +, Elronnd via Digitalmars-d-announce wrote: > On Friday, 21 January 2022 at 12:55:58 UTC, ag0aep6g wrote: > > I still believe it should be fairly simple: > > > > https://forum.dlang.org/post/ofc0lj$2u4h$1...@digitalmars.com > > There is a simpler solution: put the context pointer in rax. This is > currently a caller-saved register, so there is no problem with > clobbering it. It is used for c-style variadics, but not d-style > ones. Since it is a register, nothing breaks when you have more > parameters than fit in registers. Any other problems? This may work for x86, but does it work for other platforms? If not, it won't fly on LDC/GDC. T -- Life is complex. It consists of real and imaginary parts. -- YHL
Re: D Language Quarterly Meeting Summary for January 2021
On Friday, 21 January 2022 at 12:55:58 UTC, ag0aep6g wrote: I still believe it should be fairly simple: https://forum.dlang.org/post/ofc0lj$2u4h$1...@digitalmars.com There is a simpler solution: put the context pointer in rax. This is currently a caller-saved register, so there is no problem with clobbering it. It is used for c-style variadics, but not d-style ones. Since it is a register, nothing breaks when you have more parameters than fit in registers. Any other problems?
Re: D Language Quarterly Meeting Summary for January 2021
On 21.01.22 13:55, ag0aep6g wrote:
On 21.01.22 13:33, Mike Parker wrote:
### Mathias
Mathias would very much like to see the unification of delegates and
function pointers. There was general agreement that this is a good
goal to aim for. Mathias subsequently informed me he will look into it
once some other things are off his TODO list if no one else gets to it
first.
I still believe it should be fairly simple:
https://forum.dlang.org/post/ofc0lj$2u4h$1...@digitalmars.com
Proof of concept:
https://github.com/aG0aep6G/dmd/commit/aa0563a49536e42fe9b2c1c2d540a7f1f1b075d4
With that tiny patch, this works:
void func(int x, int y)
{
import core.stdc.stdio: printf;
printf("%d %d\n", x, y);
}
void main()
{
void delegate(int x, int y) dg;
dg.funcptr =
dg(1, 2); /* prints "1 2" */
}
Re: D Language Quarterly Meeting Summary for January 2021
On 24.01.22 03:11, Mathias LANG wrote:
Actually, the idea I had in mind is a little different.
Because a delegate is essentially:
```D
T function (T, Args..)(void* ctx, Args args)
```
It should be possible for the compiler to generate a call to a
trampoline function that just forwards to the actual function:
```D
RT _d_trampoline (FT, RT, Args..)(void* ctx, Args args)
{
return (cast(FT) ctx)(args);
}
```
As far as I'm aware, Walter is against that.
:
The compiler could, behind the curtain, generate a wrapper to do this (as you
suggest), but that has negative performance implications that users could find
very surprising because it would be hidden from them. I prefer the library
template solution for that reason.
But that was years ago, maybe he's more open to the idea now.
Re: D Language Quarterly Meeting Summary for January 2021
On Friday, 21 January 2022 at 12:55:58 UTC, ag0aep6g wrote:
On 21.01.22 13:33, Mike Parker wrote:
### Mathias
Mathias would very much like to see the unification of
delegates and function pointers. There was general agreement
that this is a good goal to aim for. Mathias subsequently
informed me he will look into it once some other things are
off his TODO list if no one else gets to it first.
I still believe it should be fairly simple:
https://forum.dlang.org/post/ofc0lj$2u4h$1...@digitalmars.com
Actually, the idea I had in mind is a little different.
Because a delegate is essentially:
```D
T function (T, Args..)(void* ctx, Args args)
```
It should be possible for the compiler to generate a call to a
trampoline function that just forwards to the actual function:
```D
RT _d_trampoline (FT, RT, Args..)(void* ctx, Args args)
{
return (cast(FT) ctx)(args);
}
```
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 15:35:17 UTC, Paul Backus wrote: The main benefit of having multiple versions available in separate namespaces is that it allows them to coexist in the same project, which means that users can migrate their code incrementally from one to the other. Yeah, I know the theory, but in practice this has limited value and works best for more fine-grained things (e.g. keeping deprecated individual functions around are more helpful than whole modules). The bigger the thing, the more likely that you'll actually introduce more bugs and compatibility issues trying to keep both versions working anyway. In principle you could also accomplish this with a versioned dub package and mangle-prefix [1], but progress on that initiative seems to have stalled out. Well, that's because it was a hopeless idea from the beginning. The in-language `import` doesn't know anything about mangles, so this concept was just asking for trouble. It would work if any only if the dependencies were *completely* isolated, but even something as simple as you importing library A who uses v1.struct at the same time as library B who uses v2.struct - even if lib A and lib B's usage of that struct was entirely `private` - is liable to cause ABI crashes. Something like PIMPL can still make it work, but there's no guarantee they did that, and likely no expectation that they would in typical D code. Anyone who has debugged extern(C) crashes after a library update knows these situations are not fun.
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 14:53:21 UTC, Adam Ruppe wrote: On Sunday, 23 January 2022 at 14:33:26 UTC, Paul Backus wrote: Absolutely-no-breakage-ever is basically the C++ approach, and I have already explained why I think it's a bad idea, though I recognize that reasonable people can disagree on this point. My view is it isn't worth shipping mixed versions at all. I'm against gratuitous breakage; it should actually provide a benefit, and I'm against dead-end breakage; it should provide a migration path. But if there's a path to a benefit, people need to make a choice: take that path, or stop updating. Any middle ground is temporary at best anyway. The main benefit of having multiple versions available in separate namespaces is that it allows them to coexist in the same project, which means that users can migrate their code incrementally from one to the other. In principle you could also accomplish this with a versioned dub package and mangle-prefix [1], but progress on that initiative seems to have stalled out. [1] https://github.com/dlang/dmd/pull/13115
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 14:33:26 UTC, Paul Backus wrote: Absolutely-no-breakage-ever is basically the C++ approach, and I have already explained why I think it's a bad idea, though I recognize that reasonable people can disagree on this point. My view is it isn't worth shipping mixed versions at all. I'm against gratuitous breakage; it should actually provide a benefit, and I'm against dead-end breakage; it should provide a migration path. But if there's a path to a benefit, people need to make a choice: take that path, or stop updating. Any middle ground is temporary at best anyway.
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 12:54:16 UTC, Adam D Ruppe wrote:
I'm not so sure. Isn't the whole point of the versioning thing
so you can use old things that haven't kept up with the latest?
When it was written, sure, they used import std because that's
easy and of course they want the latest stuff.
Then a year later, the latest has moved on and now it is broken.
Unless we ship every std version with the compiler forever,
things will break anyway, because someone will have to go back
and add `undead` as a dependency when std.v{n-1} is removed from
the official distribution.
Absolutely-no-breakage-ever is basically the C++ approach, and I
have already explained why I think it's a bad idea, though I
recognize that reasonable people can disagree on this point.
Re: D Language Quarterly Meeting Summary for January 2021
On Saturday, 22 January 2022 at 05:43:55 UTC, Paul Backus wrote: `std.v1, std.v2` We can like this: `std->std2->std`,this is very convenient! or like C++'s `/std:c++latest`.
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 04:12:30 UTC, H. S. Teoh wrote: On Sun, Jan 23, 2022 at 03:24:04AM +, Paul Backus via Digitalmars-d-announce wrote: [...] The way I envision it, `std` would be the "rolling release" namespace that allows breaking changes, and if you wanted stability, you'd have to explicitly depend on `std.vN`. What we currently call `std` would be renamed to `std.v1`. +1, this idea would work. I'm not so sure. Isn't the whole point of the versioning thing so you can use old things that haven't kept up with the latest? When it was written, sure, they used import std because that's easy and of course they want the latest stuff. Then a year later, the latest has moved on and now it is broken.
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 03:24:04 UTC, Paul Backus wrote:
The way I envision it, `std` would be the "rolling release"
namespace that allows breaking changes, and if you wanted
stability, you'd have to explicitly depend on `std.vN`. What we
currently call `std` would be renamed to `std.v1`.
module test;
@require("std.v2");
import std.stdio; // std is now std.v2
void main(){ }
Re: D Language Quarterly Meeting Summary for January 2021
On Sun, Jan 23, 2022 at 03:24:04AM +, Paul Backus via Digitalmars-d-announce wrote: [...] > The way I envision it, `std` would be the "rolling release" namespace > that allows breaking changes, and if you wanted stability, you'd have > to explicitly depend on `std.vN`. What we currently call `std` would > be renamed to `std.v1`. +1, this idea would work. T -- English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicest of all possible ways. -- Larry Wall
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 00:07:17 UTC, forkit wrote: On Saturday, 22 January 2022 at 05:43:55 UTC, Paul Backus wrote: (I think it would also be ideal if the namespace `std` were reserved for the latest stable release... wouldn't this prevent breaking changes from being allowed in a newer version of phobos? by using phobos versioning, you're free of that constraint, and people can opt in or not to a particular version of phobos. of course, then you have the problem of 'std' forever being some version.. from long..long..long ago... is this what they call 'a hard problem' ;-) The way I envision it, `std` would be the "rolling release" namespace that allows breaking changes, and if you wanted stability, you'd have to explicitly depend on `std.vN`. What we currently call `std` would be renamed to `std.v1`.
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 00:07:17 UTC, forkit wrote: I'd like to argue, that an introduction of 'phobos versioning' is a good idea, but should not be allowed in D2, but would warrant a D3 release. In D3, std phobos would always be the latest and greatest. By using D3, you agree to this, including any breaking changes introduced into that lastest and greatest version. But since each version of phobos released in D3 would have it's own version, you can always opt back into that version that works for you, at any time. This frees up phobos to be innovative, and not worry too much about breaking changes, while also not confusing new users of D, as to which version they should be using.
Re: D Language Quarterly Meeting Summary for January 2021
On Saturday, 22 January 2022 at 21:49:11 UTC, H. S. Teoh wrote: Is undead versioned? If Phobos starts innovating again, we may need to keep multiple old versions in undead for old codebases to continue working. T Why multiple old versions? Can't we just have previous implementation stored in? Then with proper versioning, you could pick up the right implementation you need for your project, just by targeting specific undead version. It is a dub project, so it can be versioned if not already.
Re: D Language Quarterly Meeting Summary for January 2021
On Saturday, 22 January 2022 at 05:43:55 UTC, Paul Backus wrote: (I think it would also be ideal if the namespace `std` were reserved for the latest stable release... wouldn't this prevent breaking changes from being allowed in a newer version of phobos? by using phobos versioning, you're free of that constraint, and people can opt in or not to a particular version of phobos. of course, then you have the problem of 'std' forever being some version.. from long..long..long ago... is this what they call 'a hard problem' ;-)
Re: D Language Quarterly Meeting Summary for January 2021
On Sat, Jan 22, 2022 at 05:09:51PM +, Alexandru Ermicioi via Digitalmars-d-announce wrote: > On Saturday, 22 January 2022 at 05:43:55 UTC, Paul Backus wrote: > > On Friday, 21 January 2022 at 12:33:25 UTC, Mike Parker wrote: > > > ### Andrei > > > Andrei brought up std.v2, but this is where memory fails me. What I > > > do recall is that there was a bit of talk about the std.v2 namespace > > > and how it will live alongside std, and this came up because Robert > > > isn't convinced the planned approach is the right way to go about > > > it. If Andrei or anyone else would like to say more about what was > > > discussed, please post something below. > > > > IMO having the `std` and `std.v2` namespaces exist alongside each other > > *in the official D distribution* would be a mistake, and would make the > > language significantly less approachable for new users. > > Imho, current design where obsolete modules are moved from phobos to undead > is a lot better. Just keep newest stuff in phobos and move old one in undead > repo. Projects still relying on old functionality, can easily just import > old module from undead project and continue using old functionality, until > they move to newest one. Is undead versioned? If Phobos starts innovating again, we may need to keep multiple old versions in undead for old codebases to continue working. T -- Perhaps the most widespread illusion is that if we were in power we would behave very differently from those who now hold it---when, in truth, in order to get power we would have to become very much like them. -- Unknown
Re: D Language Quarterly Meeting Summary for January 2021
On Saturday, 22 January 2022 at 05:43:55 UTC, Paul Backus wrote: On Friday, 21 January 2022 at 12:33:25 UTC, Mike Parker wrote: ### Andrei Andrei brought up std.v2, but this is where memory fails me. What I do recall is that there was a bit of talk about the std.v2 namespace and how it will live alongside std, and this came up because Robert isn't convinced the planned approach is the right way to go about it. If Andrei or anyone else would like to say more about what was discussed, please post something below. IMO having the `std` and `std.v2` namespaces exist alongside each other *in the official D distribution* would be a mistake, and would make the language significantly less approachable for new users. Imho, current design where obsolete modules are moved from phobos to undead is a lot better. Just keep newest stuff in phobos and move old one in undead repo. Projects still relying on old functionality, can easily just import old module from undead project and continue using old functionality, until they move to newest one.
Re: D Language Quarterly Meeting Summary for January 2021
On Friday, 21 January 2022 at 12:33:25 UTC, Mike Parker wrote: ### Andrei Andrei brought up std.v2, but this is where memory fails me. What I do recall is that there was a bit of talk about the std.v2 namespace and how it will live alongside std, and this came up because Robert isn't convinced the planned approach is the right way to go about it. If Andrei or anyone else would like to say more about what was discussed, please post something below. IMO having the `std` and `std.v2` namespaces exist alongside each other *in the official D distribution* would be a mistake, and would make the language significantly less approachable for new users. New users lack the knowledge to make and informed choice between multiple versions of the standard library, and the skills and experience necessary to manage multiple versions in a single project. Therefore, the "out-of-the-box" experience should not present them with such a choice, and should not expect them to manage multiple versions unless they explicitly opt in to doing so. Experienced D users, on the other hand, are much better equipped to deal with the complexities of multiple standard-library versions, and also much more likely to *want* to do so in the first place, since they may have existing projects that depend on older versions. In other words, they have both the means and the motivation to *opt in* to using multiple versions of Phobos. The C++ standard library prioritized backwards compatibility over good UX, and as a result is full of "legacy" traps for unwary beginners, like [`std::auto_ptr`][1] and [`std::lock_guard`][2]. In D's standard library, we have an opportunity to learn from this mistake and do better. We should not let that opportunity go to waste. (I think it would also be ideal if the namespace `std` were reserved for the latest stable release, with `std.v1`, `std.v2`, etc. available on an opt-in basis for users who wish to depend on a specific major version, but this is a much less important point.) [1]: https://en.cppreference.com/w/cpp/memory/auto_ptr [2]: https://en.cppreference.com/w/cpp/thread/lock_guard
Re: D Language Quarterly Meeting Summary for January 2021
On Friday, 21 January 2022 at 12:33:25 UTC, Mike Parker wrote: ### Adam Adam was unable to fully participate due to an issue with his microphone. He did leave comments in the text chat, and he noted that he was fine this time as an observer. We'll invite him to future meetings when his mic is working. The ever haunting issue with the microphone. It's 2022 and the microphone support on laptops/desktops still works sporadically. Don't I know it, it's been several times I had to call in with a phone instead.
Re: D Language Quarterly Meeting Summary for January 2021
On 21.01.22 13:33, Mike Parker wrote: ### Mathias Mathias would very much like to see the unification of delegates and function pointers. There was general agreement that this is a good goal to aim for. Mathias subsequently informed me he will look into it once some other things are off his TODO list if no one else gets to it first. I still believe it should be fairly simple: https://forum.dlang.org/post/ofc0lj$2u4h$1...@digitalmars.com
