Nullable or Optional? Or something else?

[Steven Schveighoffer]

On Tue, 08 Sep 2009 19:24:31 -0400, Rainer Deyke <rainerd at eldwood.com>  
wrote:

> Steven Schveighoffer wrote:
>> On Tue, 08 Sep 2009 15:50:15 -0400, Rainer Deyke <rainerd at eldwood.com>
>> wrote:
>>> Yes, in this particular case, passing a default value would work just  
>>> as
>>> well.  But what if you want to cache the contents of the entire
>>> configuration file?  What if calculating the default value is an
>>> expensive operation that should be avoided if possible?
>>
>> You're reaching here :)  A default configuration value that is expensive
>> to calculate?
>
> New example:
>
> struct AlgebraicFunction {
>   double getMaximum() {
>     if (isNull(this.cachedMaximum)) {
>       this.cachedMaximum = this.veryExpensiveCalculation();
>     }
>     return *this.cachedMaximum;
>   }
>
>   private Optional!(Optional!double) cached_maximum;
> }

Another bad example.


struct AlgebraicFunction {
    double getMaximum() {
      if (!cache_valid) {
        this.cachedMaximum = this.veryExpensiveCalculation();
        cache_valid = true;
      }
      return this.cachedMaximum; // hey, I thought you only use struct  
pointers like (*x).member?
    }

    private Optional!double cached_maximum;
    private bool cache_valid = false;
}

>
>> I understand what you are saying, but often times (as I have learned
>> from my own crusades on the NG), when it is hard to find good cases for
>> an argument, it means the argument is superficial or academic.  I could
>> very well be wrong, but to me, the practicality of the offered use cases
>> is important when evaluating whether to complicate syntax.
>
> I think it's much more important to have clear consistent semantics than
> convenient syntactic shortcuts.  I don't want D to turn into Perl.

It is clear and consistent, it's just not defined how you would like.   
What you want does not bring anything significant to the table as far as  
the vast majority of cases.

>> I thought it was to provide a way to make a value type have an "unset"
>> value.
>
> The point is to have a type that can represent all possible values of T,
> plus an additional singular value, for all possible types of T.

Here we simply disagree.

>
>>> You can't have that, because 'v' is already the container.  The best  
>>> you
>>> can get is a proxy that sometimes acts like a containee, but really
>>> isn't.  This kind of sloppy thinking has no place in computer
>>> programming.
>>
>> You mean like struct pointers? Generic type wrappers?  Remote object
>> proxies? :P
>
> These examples of proxies are also a bad idea.  When I want to access a
> member of a struct through a pointer, I use '(*p).x'.

Then you are going against well established programming techniques already  
in place in D.  Not that you aren't allowed to have your opinion, but I  
don't think it's going to get much agreement from D's developers.

-Steve