Jump to page: 1 2 3
Thread overview
D Language Quarterly Meeting Summary for January 2021
Jan 21, 2022
Mike Parker
Jan 21, 2022
ag0aep6g
Jan 24, 2022
Mathias LANG
Jan 24, 2022
ag0aep6g
Jan 24, 2022
ag0aep6g
Jan 24, 2022
Elronnd
Jan 25, 2022
H. S. Teoh
Jan 25, 2022
Elronnd
Jan 21, 2022
IGotD-
Jan 22, 2022
Paul Backus
Jan 22, 2022
Alexandru Ermicioi
Jan 22, 2022
H. S. Teoh
Jan 23, 2022
Alexandru Ermicioi
Jan 23, 2022
forkit
Jan 23, 2022
forkit
Jan 23, 2022
Paul Backus
Jan 23, 2022
H. S. Teoh
Jan 23, 2022
Adam D Ruppe
Jan 23, 2022
Paul Backus
Jan 23, 2022
Adam Ruppe
Jan 23, 2022
Paul Backus
Jan 23, 2022
Adam Ruppe
Jan 23, 2022
forkit
Jan 23, 2022
zjh
January 21, 2022

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

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

Mario had no issues to report.

Joe

Joe had no issues to report.

Robert

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

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

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

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.

Razvan & Max & Átila & Ali

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

Me

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

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

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.

Next Month

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.

January 21, 2022
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
January 21, 2022

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.

January 22, 2022

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 and std::lock_guard. 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.)

January 22, 2022

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.

January 22, 2022
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
> > > 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
January 23, 2022
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' ;-)
January 23, 2022
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.



January 23, 2022
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.

January 23, 2022
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`.
« First   ‹ Prev
1 2 3