[LLVMdev] Discussion of eliminating the void type
Duncan Sands
baldrick at free.fr
Tue May 8 00:36:36 PDT 2012
Hi Dan,
>> I am willing to do "eliminating the void type" project.
>
> Is this really a good idea? I'm not going to argue at length
> about it, but it is worth thinking about.
>
> The only practical downsides of void are when newcomers take C's
> syntax for functions with no arguments a little too literally, or
> when they try to create pointers to void. But these problems are
> quickly caught and easily corrected.
there's a difference between users of LLVM (which you discuss here)
and developers of LLVM (people writing transforms etc). I agree
that for users it just changes one oddity for another. However for
developers it should make things simpler by making the IR more uniform.
> Replacing void with {} will actually make the language more
> deceptive, because if newcomers think {} is LLVM's spelling for
> C's void, they might be tempted to use {}* for C's void*, and
> nothing will stop them except mysterious bugs if they do
> arithmetic.
I think this is a dubious argument. Being able to do pointer arithmetic
on void * was only an odd GCC extension as far as I know, not a general
C feature. Anyone who makes this mistake will pretty much instantly
discover that there is a problem. Anyway, conceptually the idea is not
to replace void with {}, it's to remove void because there are alternatives
such as {}, {{}} etc.
> On the purity side, replacing void with {} has the side effect of
> emphasising an odd asymmetry in the language. Conisder the return
> types of functions returning 0, 1, 2, and 3 etc. values:
>
> 0: {}
> 1: i32
> 2: {i32,i32}
> 3: {i32,i32,i32}
> etc.
>
> Why is 1 special-cased? Argument lists don't have a corresponding
> special case, after all.
You could return one value as {i32}. But you are right, there is an asymmetry.
It already existed, I don't see how eliminating void makes things worse, it
only makes things more regular by no longer distinguishing between the 0 case
and the 2, 3, ... case.
Ciao, Duncan.
More information about the llvm-dev
mailing list