February 03 Re: Phobos 3 Discussion Notes - 02-01-2024 | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to aberba |
On 03/02/2024 6:48 AM, aberba wrote:
> On Friday, 2 February 2024 at 15:08:37 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 03/02/2024 3:46 AM, aberba wrote:
>>> [...]
>>
>> That is not part of the current work, although Adam does have a wish list and thoughts about it.
>>
>> Please note that Phobos is getting close enough to the 64k symbol limit on Windows that we cannot be expanding its scope. So the consideration of how to architect a new standard library must occur prior to work on it.
>>
>> Starting with something that isn't just a wish list is right. It isn't some library that we can chop and change on, its going to live for 20+ years so its going to have to be designed right.
>
> I understand what you're saying however it doesn't necessarily mean "adding" to existing code. I think a lot of the old legacy stuff should be removed from new std.
Oh it will need reviewing line by line prior to copying.
So yeah that should be our default.
| |||
February 02 Re: Phobos 3 Discussion Notes - 02-01-2024 | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Lance Bachmeier | 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: You think dub should be integrated into the language? | |||
February 02 Re: Phobos 3 Discussion Notes - 02-01-2024 | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Adam Wilson | On Friday, 2 February 2024 at 09:09:37 UTC, Adam Wilson wrote: >Walter and I had a productive conversation yesterday about Phobos 3 and we felt it would be appropriate to share some notes on our discussion. [snip] When it comes to discussions around functions that allocate to the heap, I think there is some benefit in implementing lower-level functionality in functions that do not do any allocations whatsoever. You can then have higher level API above that that controls allocation and is more convenient to use. That way users can opt in to whatever they want or write their own more convenient API on top of the lower level functions. May not work for everything, but could be a useful approach. | |||
February 02 Re: Phobos 3 Discussion Notes - 02-01-2024 | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to jmh530 | On Friday, 2 February 2024 at 18:19:47 UTC, jmh530 wrote: >On Friday, 2 February 2024 at 09:09:37 UTC, Adam Wilson wrote: >Walter and I had a productive conversation yesterday about Phobos 3 and we felt it would be appropriate to share some notes on our discussion. [snip] When it comes to discussions around functions that allocate to the heap, I think there is some benefit in implementing lower-level functionality in functions that do not do any allocations whatsoever. You can then have higher level API above that that controls allocation and is more convenient to use. That way users can opt in to whatever they want or write their own more convenient API on top of the lower level functions. May not work for everything, but could be a useful approach. It may be still a bad solution. Countless times I have done functions which know how much to preallocate. The eager solution always seems to be a lot faster, and I have noticed the pattern of using This should be addressed. | |||
February 02 Re: Phobos 3 Discussion Notes - 02-01-2024 | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to jmh530 | On Friday, February 2, 2024 11:19:47 AM MST jmh530 via Digitalmars-d wrote:
> On Friday, 2 February 2024 at 09:09:37 UTC, Adam Wilson wrote:
> > Walter and I had a productive conversation yesterday about Phobos 3 and we felt it would be appropriate to share some notes on our discussion.
> >
> > [snip]
>
> When it comes to discussions around functions that allocate to the heap, I think there is some benefit in implementing lower-level functionality in functions that do not do any allocations whatsoever. You can then have higher level API above that that controls allocation and is more convenient to use. That way users can opt in to whatever they want or write their own more convenient API on top of the lower level functions.
>
> May not work for everything, but could be a useful approach.
That's certainly the approach that I think that we should be taking for a number of things (and to an extent, it's what Phobos already does with some stuff - just not everywhere). There are plenty of cases where if you really want something user-friendly, you need to be giving fewer options and just allocating stuff on the heap, but it often makes perfect sense to build that on top of much less user-friendly stuff that provides more functionality for those who really need it.
This is exactly the approach that I've taken with my socket library that I need to finish one of these days. It provides a low-level API using structs and @nogc, whereas for higher level socket stuff (e.g. code that needs to operate on sockets without caring whether they're using SSL/TLS or not), you're almost certainly going to want classes - and you're definitely going to want stuff on the heap given the need to do stuff like point to sockets on other threads to close them.
A much simpler example of this sort of thing that we already have in Phobos is range-based functions vs array functions - e.g. splitter vs split. The range-based ones are much more flexible, and they typically don't allocate (though in some cases might due to closures), but they're also much more verbose when you actually want to operate on arrays, since then you end up with calls to array all over the place, and you potentially lose out on optimization opportunites for those cases where an algorithm can be implemented more efficiently for an array. So, by having both, you have the option to avoid the allocations and work with a wider range of types - or you can use the array-specific version when you don't need those extra capabilities.
- Jonathan M Davis
| |||
February 02 Re: Phobos 3 Discussion Notes - 02-01-2024 | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Lance Bachmeier | 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: 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. >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. In any case, I have a slightly different philosophy around PR's. I do not consider bikeshedding over formatting and other trivia to be a valid reason to delay a PR. I've posted about this elsewhere. If your code passes it's tests, delivers what it says it delivers, and helps us achieve our stated goals for the release, it goes in. Will bugs escape, sure, bugs escaping is normal, but I find our habit of using bikeshedding to stall out PRs we don't agree with to be rather odious. Merge buttons exist to prevent people from tying up PR's in bureaucratic nonsense. I intend to push them. Furthermore, if you disagree with how a PR does something that is non-trivial, either offer up a competing PR or remain silent. If you do not offer up a competing PR then we will assume that you are either not as concerned as your comments make you sound, or you are not actually sure that your solution is better. In either case, you can always submit a PR to improve upon the original PR. PR's are free, let's make more of them. 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. | |||
February 02 Re: Phobos 3 Discussion Notes - 02-01-2024 | ||||
|---|---|---|---|---|
| ||||
Posted in reply to aberba | On Friday, 2 February 2024 at 17:48:30 UTC, aberba wrote: > On Friday, 2 February 2024 at 15:08:37 UTC, Richard (Rikki) Andrew Cattermole wrote: >> On 03/02/2024 3:46 AM, aberba wrote: >>> [...] >> >> That is not part of the current work, although Adam does have a wish list and thoughts about it. >> >> Please note that Phobos is getting close enough to the 64k symbol limit on Windows that we cannot be expanding its scope. So the consideration of how to architect a new standard library must occur prior to work on it. >> >> Starting with something that isn't just a wish list is right. It isn't some library that we can chop and change on, its going to live for 20+ years so its going to have to be designed right. > > I understand what you're saying however it doesn't necessarily mean "adding" to existing code. I think a lot of the old legacy stuff should be removed from new std. If you have a list of stuff that you think should be removed from Phobos, I am all ears. If you could start a discussion over in the repo that would be most helpful. https://github.com/LightBender/PhobosV3-Design/discussions | |||
February 02 Re: Phobos 3 Discussion Notes - 02-01-2024 | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to jmh530 | On Friday, 2 February 2024 at 18:03:32 UTC, jmh530 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: You think dub should be integrated into the language? It wouldn't be necessary. The compiler would only have to know how to download the source files of a Dub package if they're not currently available. Other than that, there'd be no difference to the compiler/language between this and the | |||
February 02 Re: Phobos 3 Discussion Notes - 02-01-2024 | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Adam Wilson | On Friday, 2 February 2024 at 09:09:37 UTC, Adam Wilson wrote: >Finally, we touched briefly on the major changes we would like to see in Phobos 3 and these are the major changes we are committing to for Phobos 3 so far:
https://forum.dlang.org/thread/ghsihtmlurzsuslyzgnv@forum.dlang.org | |||
February 02 Re: Phobos 3 Discussion Notes - 02-01-2024 | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Adam Wilson | 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: 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. | |||
Permalink
Reply
