Optional and orElse: design feedback/critique?

aliak something at something.com
Sun Jul 28 03:14:46 UTC 2019


On Saturday, 27 July 2019 at 19:00:13 UTC, Alexandru Ermicioi 
wrote:
> On Saturday, 27 July 2019 at 13:17:32 UTC, aliak wrote:
>> PS: I realize an obvious first comment is "what about 
>> Nullable!T". A number of reasons: 1) it doesn't have a range 
>> interface 2) the reference semantics are not desirable for me 
>> and writing generic code is awkward 
>> (https://github.com/aliak00/optional#what-about-stdtypeconsnullable), 3) alias this, although deprecated, breaks it completely, 4) maintaining a dub package feels much more productive.Skimmed a bit through main optional module, and have some questions/suggestions.
>
> Just wondering whats the reason of treating not null as being a 
> value? Per my knowledge the meaning of null basically 
> translates to "no value", does it not make sense to have null 
> be treated as empty optional, and consequently any null pointer?

I think you're right here. Will be changing this.

>
>
> Saw you're using from pattern to import symbols, wouldn't it 
> make a template bloat and increase compile time given big 
> projects?

I would assume so. Maybe. It also at the same time reduces 
compile time by lazily importing modules only if needed, i.e. 
when instantiations happen. Though, since you brought it to 
attention, I do see that it's being used in some places that 
don't make any sense (at declaration scope of the Optional for 
e.g.) So thanks for that!

>
> As for aliasing what is the problem with it? Would not it be 
> better than introspecting and defining operator overloads in 
> Optional? Existing design would introduce overhead on 
> compilation time due to introspection of payload.

I could move the operator introspection to the optional chain. I 
don't know how much overhead on compilation time this will gain. 
Have you had experience with this and do you think it's 
significant?

>
> I see you can assign value to optional payload wouldn't it be 
> better to have Optional contents pseudo immutable, and have any 
> changes defined through copies of it?

I guess so? Hmm... this one I'll have to sit on for a while

>
> Regarding toString, a sink version would be nice to have as it 
> allows nogc use of it.

Agreed!

>
> Json conversion could be outside of Optional in a separate 
> module or even project, since some people might want 
> serialization not only to vibe d.

For vibe-d it has to be inside unfortunately. But it's only 
compiled in if you're using vibe-d so I think that should be ok.

>
> If we'll treat null values as empty then won't be any need in 
> none type, and optional == null would be enough.

Indeed. That might be hard with opAssign present and T being null 
assignable.

>
> `some` for constructor of nullable is too generic name, maybe 
> rename it to optional/asOptional, it will make more sense and 
> be consistent with toOptional present in project.

indeed, also from your other post, maybe some! and no! can just 
be both replaced with optional! ... I always just liked the 
wording though.

>
> toNullable could be moved as opCast maybe.

It could. If I overload an opX explicitly for the Optional type, 
then I'll have to move all the forwarding opXs to somewhere else 
as well. Might be the way to go.

>
> Best regards,
> Alexandru.

Thanks for all the comments. It sounds like you actually went 
through the code! Much appreciated.




More information about the Digitalmars-d mailing list