December 19, 2005
Anders F Björklund wrote
>
> MicroWizard wrote:
>>
>> There are definitive difference between "uninitialized" and
>> "invalid value".
>> The first case can be handled by compiler policies.
>> The second one can't.
>>
>> The question is, should we make difference between them or not?
>>
>> If we want spare memory, we must accept bits as they are.
>> If we want to use hardware traps for floats, do the same.
>> For integers we have the choice what to do, and how to do.
> 
> I don't understand what you are trying to say here...
> 
> And I don't know *how* you could make such a "nullable"
> integer - without making it into an object like .NET/Java ?

I don't think you could.  Unless you tried reserving a bit to indicate this, and without hardware support this doesn't seem feasible.


Sean
December 19, 2005
Anders F Björklund wrote:
> MicroWizard wrote:
> 
>> Some of us lost the point :-(
> 
> 
> Several, it seems... (including me)
> 
> Sorry for hijacking your thread to whine about .init values
> 
>> There are definitive difference between "uninitialized" and
>> "invalid value".
>> The first case can be handled by compiler policies.
>> The second one can't.
>>
>> The question is, should we make difference between them or not?
>>
>> If we want spare memory, we must accept bits as they are.
>> If we want to use hardware traps for floats, do the same.
>> For integers we have the choice what to do, and how to do.
> 
> 
> I don't understand what you are trying to say here...
> 
> And I don't know *how* you could make such a "nullable"
> integer - without making it into an object like .NET/Java ?

IMHO it would be much better to keep things simple.

Wrappers around basic types add bloat and are bad for low level programming.

Reserving some values like 'int.max-1' for exceptional states works otherwise fine, but those magic values are too easily accessible, even with basic arithmetics.

I find the .init-values very useful since they simplify the process of using custom types. They also reduce the amount of code written, therefore reducing the amount of potential bugs. Float NaNs are very helpful too.

Isn't the idea of producing extra warnings for uninitialized types also against the philosophy of D? AFAIK all warnings should stop the compilation process. This would not be very helpful.

-- 
Jari-Matti
December 19, 2005
Jari-Matti Mäkelä wrote:

> I find the .init-values very useful since they simplify the process
> of using custom types. They also reduce the amount of code written,
> therefore reducing the amount of potential bugs. Float NaNs are very
> helpful too.

I'm not against the *concept* of .init-values, I think they're useful.

Still not positive whether it's "OK" to use an unintialized D integer
as having the value zero, but from the code samples it looks that way ?

> Isn't the idea of producing extra warnings for uninitialized types also against the philosophy of D? AFAIK all warnings should stop the compilation process. This would not be very helpful.

It is, just what I'm used to from other languages (such as old C / Java)
where they do break the build. And yes, this warning is sometimes false.

--anders
December 19, 2005
Jari-Matti Mäkelä wrote:
> Anders F Björklund wrote:
>>
>> I don't understand what you are trying to say here...
>>
>> And I don't know *how* you could make such a "nullable"
>> integer - without making it into an object like .NET/Java ?
> 
> 
> IMHO it would be much better to keep things simple.
> 
> Wrappers around basic types add bloat and are bad for low level programming.
> 

I don't think the OP was talking about wrapping basic types but adding a new one that is nullable.

That way i would see

int? x; as struct{ int x = int.init; bool assigned=false; } theX;

if(x is null) as if(theX.assigend == false)

f(x) as f(theX.x);

and

x=5; as theX.x=5, theX.assigned=true;

The compiler could do all this work for us.

> Reserving some values like 'int.max-1' for exceptional states works otherwise fine, but those magic values are too easily accessible, even with basic arithmetics.

I agree.

> 
> I find the .init-values very useful since they simplify the process of using custom types. They also reduce the amount of code written, therefore reducing the amount of potential bugs. Float NaNs are very helpful too.
> 

Agree also.
December 19, 2005
"MicroWizard" <MicroWizard_member@pathlink.com> wrote in message news:do6fq4$bgv$1@digitaldaemon.com...
> To solve the problem the compiler could allocate a value for
> "uninitialized" for
> every '?' types reducing the acceptable range by one value for these
> types. Also
> the compiler could manage the assignments and comparisons, not to cross
> range
> boundaries.

You could do this:

    typedef int myint = cast(int)0x80000000;

which creates your own int type that default initializes to the smallest negative value (often used as a sort of 'nan' for ints).


December 19, 2005
>>> And I don't know *how* you could make such a "nullable" integer - without making it into an object like .NET/Java ?

As I (and otherrs also) have formerly written: with ranges. (Or magic values :-)
'byte?' could be stored as a simple byte, no overhead, but the value 0x80 is
reserved to store null value.
Every assignment can be tracked by the compiler with compile-time and/or
run-time checks.
Arithmetic operations must not result 0x80.
Original range for 'byte' is 0x80-0x7f (-128 - +127)
Range for 'byte?' is 0x81-0x7f (-127 - +127)

For 'ubyte' the reserved value 0xff is more comfortable.
For 'enum A(x=0,y=1,z=2)' 3 is convenient. Just out of the range.

But this is an idea only.
If we spend some CPU time, we could get this (reserved) version,
if we spend some storage we could box integers into objects.

>> Wrappers around basic types add bloat and are bad for low level programming.
Yes. This is the problem with .NET implementation.

But the possibility is not a must. I would like to have a choice ;-)

>I don't think the OP was talking about wrapping basic types but adding a new one that is nullable.
Yes.

'int' is fast, 'int?' is convenient.

>int? x; as struct{ int x = int.init; bool assigned=false; } theX;
>...
>The compiler could do all this work for us.
Smart idea.

>> Reserving some values like 'int.max-1' for exceptional states works otherwise fine, but those magic values are too easily accessible, even with basic arithmetics.
No. Compiler could take care. Like does at array bounds.
(And should do at dealing with enums ;-)

<off topic>
Is there any movement to make enums really typesafe?
I  mean, avoid to assign any invalid integer value by range check or
some more sofisticated check.
</off topic>

>> I find the .init-values very useful since they simplify the process of using custom types. They also reduce the amount of code written, therefore reducing the amount of potential bugs. Float NaNs are very helpful too.
Yes.

Tamás Nagy


December 19, 2005
Forget the word 'initialize'. To have a non-zero initialization value is only the smallest part of the idea of 'int?'

These 'new' types make the life easier. If a function returns them you do not have to throw/catch exceptions and do not have to deal with magic values. The 'D system' compiler/runtime deals with it. Convenient only, as I've written.

In article <do7cn2$1q2i$2@digitaldaemon.com>, Walter Bright says...
>You could do this:
>
>    typedef int myint = cast(int)0x80000000;
>
>which creates your own int type that default initializes to the smallest negative value (often used as a sort of 'nan' for ints).

It does nothing with range check.
Nice but has not related to the original posting.

Sorry. Maybe my post was not detailed enough therefore misleading.

Tamás Nagy


December 20, 2005
>
> "int?" is a type like "int" but "null" is allowed signing, the variable is
> not
> initialized or is out of range.
>

Hi, TamAs

While ago I wrote an article for CodeProject about auto values (not those
'auto's)
http://www.codeproject.com/cpp/value_t.asp

The idea is simple - for each numeric type as a rule you can choose one
value
which will serve as 'undefined'  or 'null' value.

It is in C++ and  in D it is possible to do something close.

Implementation is simple and takes almost nothing as you may see.

Andrew Fedoniouk.
http://terrainformatica.com





December 20, 2005
Hi Andrew!

>While ago I wrote an article for CodeProject about auto values (not those
>'auto's)
>http://www.codeproject.com/cpp/value_t.asp
>
>The idea is simple - for each numeric type as a rule you can choose one
>value
>which will serve as 'undefined'  or 'null' value.
Thanks, it is perfectly what I've missed from D.

>It is in C++ and  in D it is possible to do something close.
I hope I could do it in D easily.

>Implementation is simple and takes almost nothing as you may see.
Yep.
The idea of 'val' is cloudy for me, and the implementation also.

Please do not be angry, I admire your helpfulness and your code, but:

Sorry to say, it is typical IT article: the write understands it and
therefore he thinks it is all clear. No. I (and I think I am not alone) need
some explanation right at the point where you have written the word 'idea'.
Why are these 'val' stuff? What is the problem with inheritance?
A detailed example would be nice.

Again, thanks a lot. The template implementation with overloaded operators is THE idea for me. The actual implementation in D won't be too hard.

Tamás Nagy


December 20, 2005
MicroWizard wrote:
>>I don't think the OP was talking about wrapping basic types but adding a new one that is nullable.
> 
> Yes.
> 
> 'int' is fast, 'int?' is convenient.
> 
> 
>>int? x; as struct{ int x = int.init; bool assigned=false; } theX;
>>...
>>The compiler could do all this work for us.
> 
> Smart idea.
> 
> 
>>>Reserving some values like 'int.max-1' for exceptional states works otherwise fine, but those magic values are too easily accessible, even with basic arithmetics.
> 
> No. Compiler could take care. Like does at array bounds.
> (And should do at dealing with enums ;-)

Ok i see now. Make a special value that tells us if the variable has been assigned to. But what about something like

struct Point{float x, y, z;}

Point? getOrNotAPoint()
{
  is(something)return null;
  else return Point(1,2,3);
}

How would compiler implement that?

The solution with ranges works great for numeric types, but what about other types?

What if i want int[]? where is that bit of information stored.


> 
> <off topic>
> Is there any movement to make enums really typesafe?
> I  mean, avoid to assign any invalid integer value by range check or
> some more sofisticated check.
> </off topic>
> 

:)