www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D Language Quarterly Meeting Summary for January 2021

reply Mike Parker <aldacron gmail.com> writes:
I had a severe case of user error going into our January meeting. 
I had previously disabled audio input in OBS Studio for a project 
I was working on. I then forgot to enable it when I recorded the 
meeting. The text chat in Jitsi Meet, which I always make a point 
to keep open when recording, provides some clues to what was 
discussed, so do my sporadic remarks (mic input was enabled). 
Mathias and Max helped fill in some gaps.

I don't believe I've missed anything big. It was a routine 
meeting with no major decisions handled. But if any of the other 
participants have more to add, they can reply in the thread.


The meeting took place on January 7, 2021, at 15:00 UTC and 
lasted a little over 1.5 hours. This was a quarterly meeting, so 
representatives from industry were present. The following people 
attended:

**D Language Foundation**

Andrei Alexandrescu
Walter Bright
Ali Çehreli
Max Haughton
Átila Neves
Razvan Nitu
Mike Parker

**Industry Reps & Contributors**

Iain Buclaw for GDC
Mario Kröplin for Funkwerk
Mathias Lang for ZeroOne (formerly known as BPFKorea)
Adam D. Ruppe as a Contributor
Robert Schadek for Symmetry Investments
Joseph Rushton Wakeling for Frequenz


Mario had no issues to report.


Joe had no issues to report.


Robert brought up a specific issue with `Nullable`:

https://issues.dlang.org/show_bug.cgi?id=22619

This led to a discussion of other `Nullable` issues. Mario said 
that Funkwerk once had their own `Optional` but moved back to 
`Nullable` a few years ago. Robert volunteered to take on 
oversight of getting `Nullable` to work like it should. He agreed 
to write up a document outlining the issues preventing it from 
working as it should. I'll follow up with him on that later.

As for the issue, Martin Kinkelin submitted a fix for it a few 
days after the meeting and Razvan merged it:

https://github.com/dlang/phobos/pull/8358


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.

He also noted that compiler releases are getting slower. We 
decided to add this topic to the agenda of a future meeting that 
includes Martin Nowak and Martin Kinkelin. Iain has subsequently 
spoken with Martin Nowak, who says that things will pick up again 
in the near future. Still, this is one of many points in our 
ecosystem that are 100% reliant upon one person, so it's 
something that should be discussed in our plans for multiple 
admins available for multiple services.


Iain gave us a summary of the work he's been doing on GDC since 
the last quarterly meeting. He raised an issue with cross 
compiling from Arm to x86 that relates to D's 80-bit reals. Iain 
can correct me if I'm wrong, but IIRC the issue is that Arm 
doesn't support 80-bit reals, so the frontend needs an emulator 
to correctly handle compile-time operations (CTFE, const folding) 
when cross compiling for x86. This is something Walter will have 
to think about.


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.


These guys had no issues to raise, though Razvan did ask Walter 
to look at this issue:

https://issues.dlang.org/show_bug.cgi?id=13162


I brought up an `alias this` issue that had come up in a 
discussion on the community Discord server:

https://issues.dlang.org/show_bug.cgi?id=5380

I advocated for the approach in the closed PR that Razvan 
submitted a fix as a few years ago:

https://github.com/dlang/dmd/pull/8815

In the discussion that ensued, the bigger problem with `alias 
this` is that fixing any issues with it will likely cause 
significant breakage. Andrei suggested that what we really need 
to do is go back to the drawing board with a DIP for a new 
feature that replaces and fixes the issues with `alias this`. We 
left it at that for now.


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.


Walter talked about the new `-vasm` switch, the disassembler he's 
added to DMD, and how he has already found it beneficial in his 
work. He noted the PR had not yet been merged, so Razvan took 
care of it.


The next meeting is a regular monthly meeting and should take 
place on February 4 at 15:00 UTC. I don't know yet what the 
agenda will be. We have a few items for which I'm awaiting news 
from others (the modified governance proposal, merging the 
DRuntime & DMD repositories, the initiative to bring all of the 
ecosystem services under the DLF with multiple admins, etc.). 
However, if you have an issue you'd like to the foundation to 
discuss and are willing to bring it to a monthly meeting, please 
let me know. We want to bring in to these meetings as many 
contributors as we can. Even with a major item on the agenda, 
there's room for one or two contributors to come in with their 
issues.
Jan 21 2022
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 21.01.22 13:33, Mike Parker wrote:


 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
Jan 21 2022
next sibling parent reply Mathias LANG <geod24 gmail.com> writes:
On Friday, 21 January 2022 at 12:55:58 UTC, ag0aep6g wrote:

 On 21.01.22 13:33, Mike Parker wrote:


 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);
}
```
Jan 23 2022
parent ag0aep6g <anonymous example.com> writes:
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.

<https://issues.dlang.org/show_bug.cgi?id=17156#c3>:

 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.
Jan 24 2022
prev sibling next sibling parent ag0aep6g <anonymous example.com> writes:
On 21.01.22 13:55, ag0aep6g wrote:

 On 21.01.22 13:33, Mike Parker wrote:


 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 = &func;
     dg(1, 2); /* prints "1 2" */
}
----
Jan 24 2022
prev sibling parent reply Elronnd <elronnd elronnd.net> writes:
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?
Jan 24 2022
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 24, 2022 at 10:56:57PM +0000, 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
Jan 24 2022
parent Elronnd <elronnd elronnd.net> writes:
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.
Jan 24 2022
prev sibling next sibling parent IGotD- <nise nise.com> writes:
On Friday, 21 January 2022 at 12:33:25 UTC, Mike Parker wrote:


 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.
Jan 21 2022
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 21 January 2022 at 12:33:25 UTC, Mike Parker wrote:


 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
Jan 21 2022
next sibling parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
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 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.
Jan 22 2022
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Jan 22, 2022 at 05:09:51PM +0000, 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 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
Jan 22 2022
parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
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.
Jan 22 2022
prev sibling next sibling parent reply forkit <forkit gmail.com> writes:
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' ;-)
Jan 22 2022
next sibling parent forkit <forkit gmail.com> writes:
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.



 Jan 22 2022



prev sibling  parent reply Paul Backus <snarwin gmail.com>  writes:


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`.



 Jan 22 2022



 next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Sun, Jan 23, 2022 at 03:24:04AM +0000, 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



 Jan 22 2022



  parent reply Adam D Ruppe <destructionator gmail.com>  writes:


On Sunday, 23 January 2022 at 04:12:30 UTC, H. S. Teoh wrote:

 On Sun, Jan 23, 2022 at 03:24:04AM +0000, 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.



 Jan 23 2022



  parent reply Paul Backus <snarwin gmail.com>  writes:


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.



 Jan 23 2022



  parent reply Adam Ruppe <destructionator gmail.com>  writes:


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.



 Jan 23 2022



  parent reply Paul Backus <snarwin gmail.com>  writes:


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



 Jan 23 2022



  parent  Adam Ruppe <destructionator gmail.com>  writes:


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.



 Jan 23 2022



prev sibling  parent  forkit <forkit gmail.com>  writes:


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(){ }



 Jan 23 2022



prev sibling  parent  zjh <fqbqrr 163.com>  writes:


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`.



 Jan 23 2022