4 ms·
>foo : &int * 8; >bar : &(int * 8); while just about anything is better than the original, we could certainly do better. I am curious how you expected to h
by knome 2y ago
>foo : &int * 8;
>bar : &(int * 8);
while just about anything is better than the original, we could certainly do better. I am curious how you expected to handle function pointer syntax, as that is the usual bear of C typing.
let's aim to make the types unambiguous, simple to read and write
all C types can take at most one parameterizing type, so prefixing works unambiguously.
force const and volatile to be exclusively prefixing as well, sorting the weirdness trailing consts would allow.
() can represent a function-pointer, with its return type following
your examples would be
ptr : *int
rgb : [3]float
foo : [8]*int
bar : *[8]int
that would leave
complex : a [](int, int)**(int,int)*const*volatile*(int,int)[][]*[][16]*char ;
vs
char *(*(* volatile * const (**a[](int , int ))(int , int ))(int , int )[][])[][16]
I couldn't have written that second one without https://cdecl.org/ https://cdecl.org/
Of course, this simple prefixing is also exactly what Go did to improve the types, with some syntactic sugar to help the reader along.
- teo_zero 2y agoOh yes, introducing expressions on types means defining a new, specific syntax for each construct. However, I strongly believe well-known symbols should keep their properties independently of whether they are used in type expression or in value expressions. So, for example, [] is already a postfix operator: it would be confusing if it was sometimes a postfix sometimes a prefix. And the unary * is already used to dereference, it would be weird if sometimes it was used to take a reference instead (for that there's already the unary &). And don't forget the precedence: you shouldn't redefine it. So &int[] would mean &(int[]) not (&int)[]. And since we're talking of a hypothetical new language, for function types I'd choose to re-use an existing operator although for a completely different meaning: ->