Crystal: `Int` should be `AnyInt` or `SomeInt`, and `Int` mean arch int width

[ozra]

Well, the title sums it up.

Before it's "too late", I really think Int should represent the pointer width on the platform (generally, exception for special architectures).

The abstract ancestor would be better of called AnyInt or SomeInt or the like.

I've tinkered with this in Onyx, but find no good solution that maintains compatibility with Crystal - which is imperative.

Having the most accessible datatype for integers represent the pointer width goes well with the fact that if you want an index or counter, it should be able to handle the addressable space.

[bcardiff]

Why is not enough to use Pointer(T) to represent a value of the address space, that also knows how to +1 with sizeof(T) information?

I am fine with Int been AnyInt and always been explicit with 32/64 alternatives (also in Floats), but not because of pointer stuff.

[jhass]

I think datatypes changing their meaning depending on the architecture the program is compiled for is a major source of confusion, at least for newcomers, I'd like to keep it as minimal as possible. So while I don't see the real problem with Int, I'm okay with freeing that name if we don't replace it with something implicitly changing.

[ysbaddaden]

I don't understand your claim at all. Anything that is architecture dependent is under LibC, like LibC::Char, LibC::Int or LibC::SizeT. I don't see any benefit for Int to become an architecture dependent pointer width, except to bring confusion...

[asterite]

I agree with @jhass and @ysbaddaden here

[asterite]

We just discussed this with @waj and we could rename Int to Integer to avoid confusion with C's int

[jhass]

And then we would need to rename Int32 to Integer32 and so on, -1, not worth it. I don't think there's actually much confusion around that.

[asterite]

No, Int32 would remain the same.

[ozra]

I for one would be very happy if Int was renamed Integer, I see no immediate reason to change the name of Int32 and Int64 because of that.
I do understand the resistance to arch-correlating Int, but if it's free to use, than one can do it in personal projects at least, at one's chosen discretion.

[jhass]

@asterite which would be a, IMO unnecessary, inconsistency.

[ozra]

The conflict with Int for c-lib interaction as mentioned by @asterite (and @waj) is justification alone imo. But I still think AnyInt or SomeInt could be better off - but that is not important as far as I'm concerned though.

[ozra]

I started on this, the painstaking replace one-by-one way.

Now, the problem is that crystal relies on a lot of implicit magic regarding Int, etc. for inheritance and resolvement.

For instance, struct Int8, defined in integer.cr doesn't inherit from Integer, explicitly stated, and so has not implemented hash (since crystal "uses" "Int" as ancestor, which has nothing deffed, since that's now on Integer).

Any advice on the best way of attacking it? This must be a two step process I guess, to be able to compile the transition. :-/

[asterite]

It's not explicitly defined because it's hardcoded in the compiler. I don't think we'll rename Int.

[ozra]

Yes, I know, that's why I reckoned a two stage process: modify compiler to be able to compile the renamed source, compile it. Then rename and use the intermediate compiler release to compile that. It would complicate one public release cycle, no doubt! There would be one release that "must not be skipped".

I'm sad to hear this change in decision, despite the slightly complicate change procedure. When going through the code, the change really made LibC code feel much more clear. Also the distinction word-wise between Integer (abstract) and Int32, Int8, LibC::Int, etc. (concrete), felt clearer in the code base at large.

I still think a change before 1.0 is the right decision.

[asterite]

I'm closing this. Having a type that changes depending on the platform is usually a big source of confusion and bugs. If you really want this you can use LibC::SizeT and others.