What if the only variable type was int?

[LB]

What if in some language very similar to C++, the only variable types were int and float. What if, for int, you had to specify signed or unsigned? (Maybe you would not have to write 'int' then)

signed int x;
unsigned int y;
int z; //syntax error 

And what if the size of int was the platform's native size, eg 32 bits on a 32 bit platform?
Well, let's say you can specify the size to the compiler, and there was a list of sizes guaranteed to be supported by all compliant compilers:

unsigned int v; //platform native size
unsigned int@8 w; //8 bit int
unsigned int@16 x; //16 bit int
unsigned int@32 y; //32 bit int
unsigned int@64 z; //64 bit int
unsigned int@65 zz; //error: unsupported size
unsigned int@24 xy; //24 bit int for 24 bit platforms, or if the compiler supported it 

What if the same was for floats?

float a; //platform native size
float@32 b; //32 bit float
float@64 c; //64 bit float aka 'double' 

If there were such a language as this, would you like or dislike these features? I'd like to know why.

Personally I think the @size feature be cool, but I have not considered all the downsides. As for the need to specify sign, I think it may be a hassle, but would prevent useless limitations from accidentally using signed rather than unsigned.

[Cubbi]

So on a 24-bit platform (hey, I've programmed for those), a program that uses @32 would not compile? It's a serious detriment if the language is not portable between platforms.

I would rather see just one integer type, one real type, and one complex type, with automatic arbitrary precision when not fitting in machine words (there are languages like that). Make the numbers match the math they come from.

PS: fun fact: the standard allows a C++ implementation where char, short, int, long, and long long are all the same size, 64 bits.

[LB]

Cubbi wrote:

So on a 24-bit platform (hey, I've programmed for those), a program that uses @32 would not compile?

LB wrote:

Well, let's say you can specify the size to the compiler, and there was a list of sizes guaranteed to be supported by all compliant compilers

[Catfish]

I personally don't like the @size argument thing. It gives the false impression one can write anything.
For example: what if I wrote int@15 i;?
Would I get an error, or would it compile by converting to 16 bits and with a warning?

[Albatross]

I'd be fine with a size parameter so long as it was instead written in terms of the number of bytes of the integer, like so:

unsigned int v; //platform native size, which would cause loads of portability issues.
unsigned int@1 w; //8 bit int
unsigned int@2 x; //16 bit int
unsigned int@4 y; //32 bit int
unsigned int@8 z; //64 bit int
unsigned int@3 xy; //24 bit int 

EDIT: I would NOT be okay with a two-type language, though.

-Albatross

[chrisname]

I'd either use a different language, or find a way around the type system.

[LB]

Chrisname you would hate such a language that much? Why? I personally like Albatross' suggestion.

[Albatross]

I suspect chrisname was referring to this:

What if in some language very similar to C++, the only variable types were int and float.

This means no convenient pointer types.

-Albatross

[LB]

Oops. I guess I meant 'primitive types' instead. I consider pointers/references atributes of variables when I am thinking in C++

[Cubbi]

There are no "primitive types" in C++, you're thinking of another language.

int is an integral type, which makes it arithmetic type, which makes it both fundamental type and scalar type, which makes it object type.

pointer to non-member is a compound type and a scalar type, which also makes it an object type

reference (either lvalue or rvalue) is a compound type, and nothing else

(I assume you were only talking about arithmetic types in the post)

[LB]

I was talking about the types from which other types could be derived. I guess I just think with different words and in diferent ways than how it is techinally...

[JLBorges]

> ... If there were such a language as this, would you like or dislike these features?

Would depend quite a lot on the precise syntax, I suppose.

I found COBOL to be too verbose for my taste:

05  BALANCE-DUE PICTURE IS S999999V99 USAGE IS COMPUTATIONAL.
* or (I thought that this was even worse)
* 05  BALANCE-DUE PIC S9(6).99 USAGE COMP.
* ...
88  RECORD-COUNT PICTURE IS 9999 USAGE IS DISPLAY.

I was quite ok with FORTRAN and PL/I:

INTEGER*2 s = 78
INTEGER*4 i = 1234
REAL*4 f = 67.8  
IMPLICIT REAL*8 Q

And comfortable with <cstdint> (it is only for integer types, though):

std::int_fast32_t count = 7 ;
std::uint16_t port = 12345 ;
std::int_least64_t seq_number = 0 ;

[Athar]

There's already such a language, it's called C++.

uint v; //platform native size
uint8_t w; //8 bit int
uint16_t x; //16 bit int
uint32_t y; //32 bit int
uint64_t z; //64 bit int
uint65_t zz; //error: unsupported size
uint24_t xy; //24 bit int for 24 bit platforms, or if the compiler supported it 

A C++ compiler that doesn't support the "guaranteed" types probably wouldn't have a compiler for that hypothetical language anyway, as it would be impractical to emulate all the standard types in software.

[helios]

What if the computer was base k? What's int@8's range? [0;2^8) or [0;k^8)?

What does "signed" mean? Is the representation defined?

*coolface*

[chrisname]

helios wrote:

What's int@8's range? [0;2^8) or [0;k^8)?

Maybe I'm misunderstanding that notation, but the minimum value for an integer wouldn't be zero, would it?

[helios]

Of course, I was talking about the unsigned type. Introducing signedness into the question would have been an irrelevant complication.

[LB]

Hence why I now prefer Albatross' idea of the number after the @ being the number of bytes rather than bits.

@Athar: Hahaha, too bad those are typedefs and not actual built-in types. I guess I've been defeated ;p

[Athar]

Hahaha, too bad those are typedefs and not actual built-in types.

And why would that matter?
What I'm saying is that this makes no difference for practical purposes, so you're describing something that already exists in C++. You'd just have to allow @ in type names and you're all set.
Speaking of which, int8/int32/float64 etc. would be easier on the eyes.

[chrisname]

If you used bytes instead of bits, wouldn't you need to know how many bits there were to a byte? It differs between architectures.

[helios]

Some compilers do have built-in types of fixed size. VC++ has __int{8|16|32|64}.


_{As an aside, does anyone know what the {|} notation is called or where it originated?}