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.

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.

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

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.