March 30, 2021
On Tuesday, 30 March 2021 at 16:05:09 UTC, Paul Backus wrote:
> On Tuesday, 30 March 2021 at 00:51:44 UTC, Andrei Alexandrescu wrote:
>> We investigated a few other possibilities, such as returning a pointer to the next element or null. But that has problems related to safety and escaping pointers.
>
> Does -preview=dip1000 help at all with these issues? If so, might be worth revisiting.

DIP1000 is not sufficient, and unsound by itself.
March 30, 2021
On 3/30/21 12:05 PM, Paul Backus wrote:
> On Tuesday, 30 March 2021 at 00:51:44 UTC, Andrei Alexandrescu wrote:
>> We investigated a few other possibilities, such as returning a pointer to the next element or null. But that has problems related to safety and escaping pointers.
> 
> Does -preview=dip1000 help at all with these issues? If so, might be worth revisiting.

A good point.
March 31, 2021
On 2021-03-24 20:23, Per Nordlöw wrote:
> What's the motive behinds D's range design choice of needing
> 
>     if (!empty)
>     {
>         // use front or back
>     }
> 
> instead of having front returning an optional/maybe type with enforced pattern matching?

In my opinion, the best way to interact with an Optional type is not to use pattern matching but to use algorithms like `map`, `each` and so on. That means an Optional type needs to implement the range API. Might be a bit confusioning if `front` then returns an Optional.

-- 
/Jacob Carlborg
March 31, 2021
On Tuesday, 30 March 2021 at 00:51:44 UTC, Andrei Alexandrescu wrote:
> Efficiency. It would be impossible to iterate an array as a range without copying each and every element thereof.

On an efficiency-related note, it's worth remembering that the `empty` property can be a compile-time constant (as it is e.g. with pseudo-random number generators), which means that in some cases it should be possible (at least in principle) to elide any `empty` checks at runtime.

I imagine there is a way to achieve the same effective outcome with an appropriately designed Option type or trait, but I don't know if that would be as straightforward as with the `empty` property.

> We investigated a few other possibilities, such as returning a pointer to the next element or null. But that has problems related to safety and escaping pointers.

This is probably a factor in Rust's decision to use Option<T>: its iterators over containers do use references (i.e. smart pointers), and this is easier option for them because of the stronger reference safety constraints.
April 05, 2021

On Wednesday, 31 March 2021 at 07:27:18 UTC, Jacob Carlborg wrote:
way to interact with an Optional type

>

is not to use pattern matching but to use algorithms like map, each and so on.

Interesting. Can you show some pseudocode of this? Can those algorithms be implemented as non-member functions?

April 05, 2021

On Monday, 5 April 2021 at 20:01:46 UTC, Per Nordlöw wrote:

>

On Wednesday, 31 March 2021 at 07:27:18 UTC, Jacob Carlborg wrote:
way to interact with an Optional type

>

is not to use pattern matching but to use algorithms like map, each and so on.

Interesting. Can you show some pseudocode of this? Can those algorithms be implemented as non-member functions?

The optional package on dub [1] has some examples in its documentation.

[1] https://code.dlang.org/packages/optional

April 05, 2021

On Monday, 5 April 2021 at 20:11:07 UTC, Paul Backus wrote:

>

The optional package on dub [1] has some examples in its documentation.

Thanks. What about adding these algorithms to std.sumtype?

April 05, 2021

On Monday, 5 April 2021 at 20:33:44 UTC, Per Nordlöw wrote:

>

On Monday, 5 April 2021 at 20:11:07 UTC, Paul Backus wrote:

>

The optional package on dub [1] has some examples in its documentation.

Thanks. What about adding these algorithms to std.sumtype?

Optional implements the standard range interface, so the algorithms it uses are the existing ones in std.algorithm.

April 05, 2021

On Monday, 5 April 2021 at 20:38:33 UTC, Paul Backus wrote:

>

Optional implements the standard range interface, so the algorithms it uses are the existing ones in std.algorithm.

Ah, of course. Are you planning on adding Optional to Phobos aswell?

April 05, 2021

On Monday, 5 April 2021 at 20:46:07 UTC, Per Nordlöw wrote:

>

On Monday, 5 April 2021 at 20:38:33 UTC, Paul Backus wrote:

>

Optional implements the standard range interface, so the algorithms it uses are the existing ones in std.algorithm.

Ah, of course. Are you planning on adding Optional to Phobos aswell?

No, because it's not my package, it's Ali Akhtarzada's.