Motive behind !empty() with front() instead of Optional front()
uranuz
neuranuz at gmail.com
Mon Mar 29 18:16:56 UTC 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.
Hello! It is a good idea what are you talking about. But I agree
that it's better to implement it as some method using UFCS. So
this will not break anything.
Also I want to say that for me most of the times I check for *non
empty* rather than *empty*. So every time I need to write
exclamation mark before it. It is not very comfortable. But the
problem is that I can't say antonym for the word *empty*. It
actually shall not be antonym, but the word that say that this
range should have at least one element. My variants are: hasNext,
hasFront, hasMore, hasAny or smth like that.
The problemme with *empty* is that it has some *negative*
meaning. But I read somewhere recommendations to prefer
*positive* words for boolean flags except for rare cases where
*negative* flags are simplier to work with, because of domain
area where it's used.
But I believe that range is not such a case. And I explained by
my own experience that mostly I test for *hasMore* then for
*empty*.
Sorry for slightly off-topic post ;-)
More information about the Digitalmars-d
mailing list