March 10, 2023

On Thursday, 9 March 2023 at 17:07:40 UTC, Paul Backus wrote:

>

I think probably you have to go on a case-by-case basis. File.byLine, for example, does not and should not precompute front, because doing so is potentially very expensive.

And then ‘File.byLine’ ends up being const and now you can’t call ‘front’ on it. Ouch.

March 10, 2023

On Friday, 10 March 2023 at 13:46:03 UTC, Ogi wrote:

>

On Thursday, 9 March 2023 at 17:07:40 UTC, Paul Backus wrote:

>

I think probably you have to go on a case-by-case basis. File.byLine, for example, does not and should not precompute front, because doing so is potentially very expensive.

And then ‘File.byLine’ ends up being const and now you can’t call ‘front’ on it. Ouch.

Ranges already don't work with const, so the fact that this one fails to work with const a little more than usual is not a huge deal, IMO.

March 11, 2023
On 3/10/23 23:47, Paul Backus wrote:
> On Friday, 10 March 2023 at 13:46:03 UTC, Ogi wrote:
>> On Thursday, 9 March 2023 at 17:07:40 UTC, Paul Backus wrote:
>>>
>>> I think probably you have to go on a case-by-case basis. `File.byLine`, for example, does not and should not precompute `front`, because doing so is potentially very expensive.
>>
>> And then ‘File.byLine’ ends up being const and now you can’t call ‘front’ on it. Ouch.
> 
> Ranges already don't work with `const`, so the fact that this one fails to work with `const` a little more than usual is not a huge deal, IMO.

`const` tends to just not work really well together with abstraction.
"`const` correctness" in D is a fool's errand.
March 12, 2023

On Saturday, 11 March 2023 at 19:52:06 UTC, Timon Gehr wrote:

>

On 3/10/23 23:47, Paul Backus wrote:

>

On Friday, 10 March 2023 at 13:46:03 UTC, Ogi wrote:

>

On Thursday, 9 March 2023 at 17:07:40 UTC, Paul Backus wrote:

>

I think probably you have to go on a case-by-case basis. File.byLine, for example, does not and should not precompute front, because doing so is potentially very expensive.

And then ‘File.byLine’ ends up being const and now you can’t call ‘front’ on it. Ouch.

Ranges already don't work with const, so the fact that this one fails to work with const a little more than usual is not a huge deal, IMO.

const tends to just not work really well together with abstraction.
"const correctness" in D is a fool's errand.

Should we just remove const then and get it over with?

March 12, 2023
On 3/12/23 11:06, Tejas wrote:
> On Saturday, 11 March 2023 at 19:52:06 UTC, Timon Gehr wrote:
>> On 3/10/23 23:47, Paul Backus wrote:
>>> On Friday, 10 March 2023 at 13:46:03 UTC, Ogi wrote:
>>>> On Thursday, 9 March 2023 at 17:07:40 UTC, Paul Backus wrote:
>>>>>
>>>>> I think probably you have to go on a case-by-case basis. `File.byLine`, for example, does not and should not precompute `front`, because doing so is potentially very expensive.
>>>>
>>>> And then ‘File.byLine’ ends up being const and now you can’t call ‘front’ on it. Ouch.
>>>
>>> Ranges already don't work with `const`, so the fact that this one fails to work with `const` a little more than usual is not a huge deal, IMO.
>>
>> `const` tends to just not work really well together with abstraction.
>> "`const` correctness" in D is a fool's errand.
> 
> Should we just remove `const` then and get it over with?

`const` is fine for POD. Things like `scope const(ubyte)[]` are useful.
It's just not a good match for abstract data types.
March 12, 2023

On Thursday, 9 March 2023 at 08:06:02 UTC, FeepingCreature wrote:

>

Yes I know the stated reason, to save time initializing the range in filter.

You know what I did because we didn't know filterBidirectional existed?

I literally walked the entire range returned by filter to find the last matching element.

filter should expose back. By all means, let back lazily initialize, but I don't understand how filterBidirectional was ever considered acceptable. Since when do we sacrifice ease of use for performance? I mean, since 2011 apparently. - This is bad ergonomics, bad discoverability and bad API design. filterBidirectional delenda est.

I agree with you that it probably should be bidirectional by default. I don't agree with making back lazy (but that is perhaps a separate topic). It probably should have a compile time flag to enable bidirectional iteration (on by default).

April 14, 2023

On Thursday, 9 March 2023 at 08:06:02 UTC, FeepingCreature wrote:

>

Yes I know the stated reason, to save time initializing the range in filter.

You know what I did because we didn't know filterBidirectional existed?

I literally walked the entire range returned by filter to find the last matching element.

filter should expose back. By all means, let back lazily initialize, but I don't understand how filterBidirectional was ever considered acceptable. Since when do we sacrifice ease of use for performance? I mean, since 2011 apparently. - This is bad ergonomics, bad discoverability and bad API design. filterBidirectional delenda est.

I agree with the sentiment here, but I do wonder about unintended consequences of pre-computing back as well as front.

Atila

April 18, 2023

filterBidirectional exists to provide a way to filter signals in both directions, which is necessary for specific applications. It is not simply called a filter because the standard filter function only filters in one direction, and does not provide this bidirectional capability.

1 2
Next ›   Last »