Current sentiment on Nullable.get

[aliak]

On Tuesday, 11 December 2018 at 18:04:37 UTC, H. S. Teoh wrote:
> On Tue, Dec 11, 2018 at 08:44:03AM +0000, aliak via 
> Digitalmars-d wrote:
>> On Monday, 10 December 2018 at 17:07:10 UTC, jmh530 wrote:
>> > On Monday, 10 December 2018 at 15:47:53 UTC, aliak wrote:
>> > > [...]
>> > 
>> > Does it make sense to deprecate Nullable as a whole, rather 
>> > than just that piece? Why would I use Nullable when I can 
>> > use your optional library?
>> 
>> I would be all for that. I guess the only reason would be to 
>> have
>> pointer semantics for value types 🤷‍♂️And I'm not really sure why
>> you'd want that anyway.
>
> It's useful for representing a value that isn't there.  E.g., 
> if I have a struct with some int fields parsed from some config 
> file, say, I'd like to be able to distinguish between a field 
> that's actually set, vs. one that isn't specified in the config 
> file.
>
>
> T

True! Sorry, I meant that as a response to "why would i use 
Nullable over the mentioned Optional library". In that case 
optional represents existence, and then the only thing nullable 
has over that is pointer semantics. But I think pointer semantics 
is a poor representation of the existence of a value. What's the 
difference between using Nullable!int and int* to see if it's set 
in terms of intent/semantics/safety? (I realize allocation would 
be a difference).

Cheers,
- Ali