Dynamic arrays, basic type names, auto

[Yigal Chripun]

bearophile wrote:
> Yet another of my lists of silly suggestions, this time shorter :-)
> 
> A syntax like this (that is a bit hairy, I agree) may be useful for time-critical spots in the code:
> 
> auto arr = new int[1_000_000] = int.max;
> auto arr = new int[1_000_000] = void;
> 
> --------------------------
> 
> I may appreciate D 2.0 to have its basic types named like this:
> 
> - int1 int2 int4 int8
> - uint1 uint2 uint4 uint8
> (Fixed size. The number is their length expressed in bytes (shorter than using bits). There aren't int16 / uint16 yet)
> 
> - int
> (built-in multi-precision signed integer. The compiler has heuristics to replace it with a faster fixed size integer in lot of situations. Optimized (if necessary modifying the GC too) for very short numbers that can fit in just 4-8 bytes, so even where the compiler isn't able to replace it with a fixed sized integer the slowdown isn't too much big, this is to hopefully let C++/C programmers be less scared of them. People that need to compute operations on very large integers have to tolerate a bit of constant slowdown, or use GMP).
> 
> - word uword
> (They are the default size of the CPU, 4, 8 or 16 or 32 bytes, so their size isn't fixed. 'word' replaces the current 'size_t')
> 
> I don't like this much, but I don't see better alternatives so far (you need less memory to remember them and dchar, wchar, char):
> - char1, char2, char4
> (They are unicode. char1 is often 1 byte, and char2 is often 2 bytes long, but they may grow to 4, so they aren't fixed size)
> 
> - str
> (replaces the current 'string'. Strings are used all the time in certain kinds of code, so an identifier shorter than 'string' may be better)
> 
> - bool null true false void
> (Java uses 'boolean', but 'bool' is enough for D).
> 
> - set
> (built-in set type, often useful, see Python3 and Fortress)
> 
> - list (or sequence, or seq)
> (Haskell uses "2-3 finger trees" to implement general purpose sequences, they may be fit for D too, they aren't meant to replace arrays
> http://en.wikipedia.org/wiki/Finger_tree ).
> 
> Plus something else for float/double/real complex types.
> 
> -----------------------
> 
> D used 'auto' for automatic typing of variables:
> auto s = "hello";
> 
> C# uses 'var', that's just 3 chars long and equally readable:
> var s = "hello";
> 
> 'let' is more logic, shorter than 'auto' and it was used in Basic too:
> let s = "hello";
> 
> 'var' can be written on the keyboard with just the left hand, so it may be written even faster than 'let'. But 'var' in modern D replaces 'inout'. So I think 'let' may be a good compromise for D.
> 
> Bye,
> bearophile

Fortran uses int4 and such. Do we really want to go back to that?
I personally dislike all those Fortran suggestions but I agree that the
current C style also can be improved, so here's my idea:
let's generalize the type system. Scala for example has a value type and
a reference type that all types inherit from accordingly.
What I mean is that I'd like the basic types to become oop objects so
that you can use a more uniform syntax.
currently in D:
auto x = new Class;
int y;
x.toString;
toString(y);
I'd prefer to be able to do:
y.toString;

Note: I do not want boxing like java/c#, but rather make the basic type
themselves act like objects.

I think this could be implemented as special structs known by the compiler.

the types will get "constructors" so that the number of reserved
keywords can be reduced.
for example:
- int will be unbounded integer that the compiler can optimize its
internal representation according to its value.
- int(size) for a fixed size int. so int(4) is the same as the above
int4 in bearophile's suggestion.
for signed/unsigned we can have an "unsigned" keyword, a similar "uint"
type or maybe just another type-constructor: int(4, u) would be unsigned
4 byte int.
- word/byte or maybe even machine(word)/machine(byte)
- floatig point: float(fast)/float(large)/float(size)/etc..
- fixed point: fixed(size) or decimal(size)
etc..

that's just a rough draft of an idea..

-- Yigal