References in D

[Chad J]

On 10/07/2012 02:22 AM, David Piepgrass wrote:
>> void main()
>> {
>> void* x = a(b());
>> c();
>> while(goobledegook)
>> {
>> x = p();
>> d(x);
>> }
>> e(x); /+ Crash! x is null. +/
>> }
>>
>> Where did x's null value come from? Not a. Not p; the while loop
>> happened to be never executed. To say "b" would be closer, but still
>> imprecise. Actually it was created in the q() function that was called
>> by u() that was called by b() which then created a class that held the
>> null value and was passed to a() that then dereferenced the class and
>> returned the value stored in the class that happened to be null. nulls
>> create very non-local bugs, and that's why they frustrate me to no end
>> sometimes.
>
> Since this thread's attracted lots of commotion I thought I'd just drop
> by and +1 for non-nullable types, and +1 for your arguments.
>
> I keep wondering, though, if it is 'enough' to solve the null problem,
> or if it would be possible to devise a more general mechanism for
> solving other problems too, like say, the fact that certain integers
> have to always be positive, or if you want to go more general, that a
> certain relationship must hold between two structures...
>

I agree.

> Not having used D's invariants so far (well, I haven't used D itself for
> a real project actually)... what's stopping D's invariant mechanism from
> handling all this?
>
> http://dlang.org/class.html#invariants (as is typical of D
> documentation, this says nothing about invariants on structs, but the
> page about structs says that they support invariants with an X.)
>
> I mean, problems are detected at runtime this way, and slightly too
> late, but still, it would be better than most popular languages that
> can't do anything about nulls at all. Since D's devs don't even seem to
> have enough time to implement D as described in TDPL (published more
> than two years ago), I wouldn't expect to see this feature in the D
> language in the near future.

Invariants might work... create a proxy struct and then have assignment 
always check the invariant.  I don't like the idea that they get removed 
during release mode.  I'd like to be able to control which checks I pay 
for.  I think this might just mean that the important thing is 
overloading assignment to do checks, which could be done in principle, 
and this could work without invariants and thus give the desired control.

I just haven't had much luck creating proxy types in the past.  As of 
some months ago, D just wasn't there yet.  :(

In another post in this thread I mentioned something similar:

>
> It would be cool to have templates like this:
>
> 51.  bool isPrime(int val)
> 52.  {
> 53.      ...
> 54.  }
>
> 101. Watch!(int,&isPrime) primeNumber = primeGenerator();
> 102. primeNumber = 8;
> 103. doStuff();
> 104. checkPrime(primeNumber); /+ Crash! +/
> Error: checkPrime(primeNumber): primeNumber is not prime.
> primeNumber: isPrime returned false after assignment at
>   (foobar.d, line 102)
>
> ~or~
>
> 101. Constrain!(int,&isPrime) primeNumber = primeGenerator();
> 102. primeNumber = 8; /+ Crash! +/
> 103. doStuff();
> 104. checkPrime(primeNumber);
> foobar.d, line 102: isPrime returned false after assignment.
>
> For convenience one could define this:
> alias Constrain!(int,&isPrime) PrimeInt;

Maybe these could be turned on/off in release mode on a case-by-case 
basis.  I would probably leave the checks and tracking in always, with 
the one exception of code that has been shown (with profiling) to need 
the extra performance.