Jump to page: 1 26  
Page
Thread overview
Motive behind !empty() with front() instead of Optional front()
Mar 24, 2021
Per Nordlöw
Mar 24, 2021
Meta
Mar 24, 2021
IGotD-
Mar 24, 2021
Per Nordlöw
Mar 24, 2021
IGotD-
Mar 24, 2021
Paul Backus
Mar 25, 2021
Jesse Phillips
Mar 25, 2021
deadalnix
Mar 25, 2021
Rumbu
Mar 25, 2021
Per Nordlöw
Mar 26, 2021
Piotr Mitana
Mar 26, 2021
Per Nordlöw
Mar 26, 2021
Per Nordlöw
Mar 26, 2021
Nick Treleaven
Mar 26, 2021
Per Nordlöw
Mar 26, 2021
Nick Treleaven
Mar 26, 2021
vitoroak
Mar 26, 2021
Per Nordlöw
Mar 26, 2021
Paul Backus
Apr 06, 2021
Q. Schroll
Apr 06, 2021
Paul Backus
Apr 06, 2021
Per Nordlöw
Apr 06, 2021
Per Nordlöw
Apr 06, 2021
Per Nordlöw
Apr 06, 2021
Paul Backus
Apr 06, 2021
Per Nordlöw
Apr 08, 2021
Max Haughton
Apr 07, 2021
Q. Schroll
Apr 07, 2021
Paul Backus
Apr 09, 2021
Q. Schroll
Apr 09, 2021
Paul Backus
Apr 10, 2021
Q. Schroll
Apr 08, 2021
Paul Backus
Mar 26, 2021
Per Nordlöw
Mar 26, 2021
Nick Treleaven
Mar 27, 2021
Nick Treleaven
Mar 29, 2021
uranuz
Mar 30, 2021
Paul Backus
Mar 30, 2021
deadalnix
Mar 30, 2021
Per Nordlöw
Mar 30, 2021
Per Nordlöw
Mar 31, 2021
Jacob Carlborg
Apr 05, 2021
Per Nordlöw
Apr 05, 2021
Paul Backus
Apr 05, 2021
Per Nordlöw
Apr 05, 2021
Paul Backus
Apr 05, 2021
Per Nordlöw
Apr 05, 2021
Paul Backus
Apr 05, 2021
Per Nordlöw
Apr 05, 2021
Paul Backus
Apr 07, 2021
Jacob Carlborg
March 24, 2021
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?

Lack of builtin Optional type?

Choosing the Optional path would have avoided the need for putting error diagnostics such as

https://github.com/dlang/phobos/commit/9bd2f2ba8ff1124a044560c4e6912a13cb5ac694

in the standard library of such an alternative solution.
March 24, 2021
On Wednesday, 24 March 2021 at 19:23:21 UTC, 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?
>
> Lack of builtin Optional type?
>
> Choosing the Optional path would have avoided the need for putting error diagnostics such as
>
> https://github.com/dlang/phobos/commit/9bd2f2ba8ff1124a044560c4e6912a13cb5ac694
>
> in the standard library of such an alternative solution.

Most/all of the range stuff was Andrei's idea, and his C++ background heavily informed the design. Returning Optional<T> to represent that a calculation might fail is not common in C++, or at least wasn't back then. In general, more functional-oriented techniques have only recently started diffusing into the C++ culture (or at least it feels that way to me; I don't really follow C++ closely anymore).
March 24, 2021
On Wednesday, 24 March 2021 at 19:32:22 UTC, Meta wrote:
>
> Most/all of the range stuff was Andrei's idea, and his C++ background heavily informed the design. Returning Optional<T> to represent that a calculation might fail is not common in C++, or at least wasn't back then. In general, more functional-oriented techniques have only recently started diffusing into the C++ culture (or at least it feels that way to me; I don't really follow C++ closely anymore).

That it is because of historical reasons makes sense. From a programming point of view, it doesn't really matter since you must check your Optional<T> return value anyway and you still get a check regardless. Performance wise it doesn't matter.

Another motive would be that it would force to check if the return value is not empty, however you might not want that. For example in a loop and you know the amount of elements in advance then the check is unnecessary.
March 24, 2021
On Wednesday, 24 March 2021 at 21:09:52 UTC, IGotD- wrote:
> For example in a loop and you know the amount of elements in advance then the check is unnecessary.

Are you talking about a foreach loop? If so, the element type will never have to be an optional type. Regardless of whether `front` is wrapped in an Optional or not.
March 24, 2021
On Wednesday, 24 March 2021 at 21:20:40 UTC, Per Nordlöw wrote:
>
> Are you talking about a foreach loop? If so, the element type will never have to be an optional type. Regardless of whether `front` is wrapped in an Optional or not.

Could be a foreach loop but also a counted loop, you want to go through a certain amount of elements and you know for sure with check before that the elements exist. I'm not sure if I understand your statement, but wrapping such a loop with Optional<T> would lead to an extra overhead and since it is inside a loop it is not insignificant. I wouldn't trust an optimizer would understand how to remove such check.

Now the possibility is to have to versions of front, one that returns the element and another that returns Optional<T> (why do I write C++ syntax?). Not sure if that would lead to ambiguous case problems.
March 24, 2021
On Wednesday, 24 March 2021 at 21:09:52 UTC, IGotD- wrote:
> Another motive would be that it would force to check if the return value is not empty, however you might not want that. For example in a loop and you know the amount of elements in advance then the check is unnecessary.

If you know the Optional isn't empty you can just call `.unwrap` (or whatever it ends up being called) to get the value without checking.
March 25, 2021
On Wednesday, 24 March 2021 at 19:23:21 UTC, 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?
>
> Lack of builtin Optional type?
>
> Choosing the Optional path would have avoided the need for putting error diagnostics such as
>
> https://github.com/dlang/phobos/commit/9bd2f2ba8ff1124a044560c4e6912a13cb5ac694
>
> in the standard library of such an alternative solution.

Is optional not having a value a good way to know you are at the end of a list? I know that Nullable can use a flag, but if you return an optional with a value of null, feels like you are defeating the purpose of optional.
March 25, 2021
On Wednesday, 24 March 2021 at 19:23:21 UTC, 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?
>
> Lack of builtin Optional type?
>
> Choosing the Optional path would have avoided the need for putting error diagnostics such as
>
> https://github.com/dlang/phobos/commit/9bd2f2ba8ff1124a044560c4e6912a13cb5ac694
>
> in the standard library of such an alternative solution.

The big question is, what if I want a range of Optional!T ?
March 25, 2021
On Thursday, 25 March 2021 at 09:35:40 UTC, deadalnix wrote:
> On Wednesday, 24 March 2021 at 19:23:21 UTC, 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?
>>
>> Lack of builtin Optional type?
>>
>> Choosing the Optional path would have avoided the need for putting error diagnostics such as
>>
>> https://github.com/dlang/phobos/commit/9bd2f2ba8ff1124a044560c4e6912a13cb5ac694
>>
>> in the standard library of such an alternative solution.
>
> The big question is, what if I want a range of Optional!T ?

You have to check on Optional!(Optional!T).

March 25, 2021
On Thursday, 25 March 2021 at 09:35:40 UTC, deadalnix wrote:
> The big question is, what if I want a range of Optional!T ?

That might lead to confusing code, yes. Aliases or subtypes could come of use in such a situation. Better ask the Rust forums...
« First   ‹ Prev
1 2 3 4 5 6