Phobos 3 Discussion Notes - 02-01-2024

[Lance Bachmeier]

On Friday, 2 February 2024 at 18:57:48 UTC, Adam Wilson wrote:
> On Friday, 2 February 2024 at 16:46:29 UTC, Lance Bachmeier 
> wrote:
>> On Friday, 2 February 2024 at 14:46:45 UTC, aberba wrote:
>>
>> A better solution would be something like this:
>>
>> ```
>> dub dxml;
>>
>> void main() {
>>   // Call functions from the dxml package
>> }
>> ```
>>
>> The compiler would know about certain popular packages on 
>> code.dlang.org. It would download the package if needed, and 
>> it would know where to find the relevant files.
>
> I cannot argue strenuously enough against putting the packaging 
> system in to the compiler directly. Not only will it balloon 
> the build times by orders of magnitude, it is a serious 
> violation of separation-of-concerns. The compiler should 
> concern itself with compiling code and nothing else. The 
> compiler is the wrong place to be handling third-party 
> packages, that is properly the venue of the build system.

I responded to the other comment, but I'll give the same answer. 
What I'm proposing doesn't have anything to do with the packaging 
system, Dub, or any of that. The only thing the compiler would 
have to know is how to download the source files of a package if 
they haven't already been downloaded.

>> There are good reasons to not add that stuff to Phobos. The 
>> standard to get something in Phobos is high enough that it 
>> leads to a lot of wasted time for many people, it doesn't 
>> bloat the compiler download size, it takes advantage of work 
>> that's already been done, and it could be done quickly, rather 
>> than the years it takes to get stuff done otherwise. (I'm 
>> writing this fully aware of how things get done around here, 
>> but I'm going to put it out there anyway.)
>
> People always say there are good reasons, but are light on 
> actual reasons. Saying that Phobos has a high bar is not itself 
> a reason so much as an excuse to not make the effort.

A sufficient reason is that I know how things get done around 
here, and an updated Phobos with these additions will 
optimistically be released in 2032. Most of the work has already 
been done. Why not reuse it?

It's been eight months since I proposed a simple solution to the 
problem that library writers have to support too many compiler 
releases. Label some compiler releases as not being supported by 
library writers. It would have solved the problem fully and it 
could have been done by the end of the day. Obviously we couldn't 
do that. Instead we got editions. Eight months later, we still 
don't have an initial proposal, and the problem for library 
writers continues.

> Under my watch (if the community doesn't kick me out) Phobos 
> will move faster. And yes, there might even be more bugs that 
> escape. My plan is to use the monthly(Atila?) releases between 
> the major roll-up releases mentioned in my original post to 
> catch them before they get to the wider population.

I hope that's true. It's hard to change the culture of any 
organization, especially one built on volunteer labor.