I work in compilers, but typically on the back-end, so I'm usually operating past the point of type-checking / IR generation / etc. Something that's confused me when working on both GPU and CPU compilers is that alignment is typically not considered part of the type system in most languages. Obviously C doesn't do this, but it also hasn't been a priority in most recent languages, e.g. Go/Rust/Swift/D/etc. -- I do know that Zig has something going on here, but AFAICT it's the only one. Rather those languages treat it as a property of a pointer. For fully scalar code this is kinda fine, but anything SIMD/SIMT/whatever struggles greatly from the fact that you can't even e.g. pass an alignas buffer into another function without screwing the optimizer (unless of course you inline everything, which is what people do in practice...). Given the surge in popularity of GPU compilers, and even on the CPU side how much focus has been on autovectorization for the last decade, you'd think that there'd be more of an impetus to make alignment a first-class citizen. E.g. have functions be able to specify the alignment of arguments, have function types be automatically contravariant over those specs, etc.
I'm sure some of this comes down to the fact that this is how LLVM treats it -- but that just shunts the question to why these IRs all take similarly pessimizing approaches. Even MLIR handles this pretty poorly IMO. All of that indicates, to me, that something about this is harder than I expect.
So for people on the frontend side of the world, what makes this difficult, or why is it not attractive in language design?
What would people prefer more?
Implicit type conversion - Type have conversion rules and convert based on that. Like what C has.
Overload type conversion - Have overloading operator functions that convert types from one form to another. If an overload isn't present, there is no mechanism, no any or void * for intermediate casting.
OR
Explicit type conversion - Using either the syntax of mentioning the type before or after the variable or type(anothertype) syntax.
I like implicit ones as they are so clean but they are highly error prone imo. Even as a C user I do not really use implicit type conversion.
I wanna know how other people feel about it?
Now the second question is, which syntax would you prefer:
C like syntax:
type-qualifier storage-qualifier type-specifier [*type-qualifier storage-qualifier type-specifier] variable
Go/TS/Rust like syntax:
var/let/const variable [:] [mut] [*] type specifier
Go inspired my version of syntax:
variable/VARIABLE type/p_type/r_type
-
VARIABLE means it is a constant, compile time or runtime or in that scope.
-
variable means it is not a constant.
-
p_type is a pointer of type type.
-
r_type is a reference of type type.
-
Optionally, I am also wondering if we can use shadowing and if a scope has abc and I write
ABC = abcI can have basically a constant in a scope after a certain point which can be used for compiler optimizations. This can only be done if the spelling is the same with ALL CAPS. And I can't useabcafter that line.