3 ms·

Polymorphic types are certainly useful, and I wish C had a better way to go about it, but this proposal feels like an odd patch to C's type system. Especially t

by injuly 3y ago

Polymorphic types are certainly useful, and I wish C had a better way to go about it, but this proposal feels like an odd patch to C's type system. Especially this part: ``` Using a run-time value of type _Type T in _Var(T) can be allowed in general (and is useful), but needs to be restricted to contexts where full type information is not required at compile-time. ``` Semantic rules that conditionally apply only in some contexts is a common tendency of the C++ standard that many C programmers often dislike.

nxobject 3y ago
Here is another way in which this is a little patch-like. The author observes that: (a) it is desired that _Var(T)* and void* be compatible; (b) however. pointers-to-T for different T are not guaranteed to be compatible in general, as a consequence, it is NOT guaranteed that _Var(T)* is compatible with T*, which is a theoretical wart worthy of C++. I can see it becoming especially annoying if you’re trying to introduce _Var(T) polymorphism into a code base that currently uses preprocessor macros that textually substitute types. Perhaps the better solution would be forgo giving void* any special status whatsoever. However, that means that this type of polymorphism can’t be implemented using void* as a polyfill.
uecker 3y ago
I don't think this is a deficiency, but an inherent property of powerful type systems. If you make them very expressive, then you can not have full type checking at compile time. On the other hand, if you restrict them so that you do full static type checking, than they are very limited.
- nxobject 3y ago
  It's a natural limit – but it doesn't make it easy to figure out in advance when it is/isn't permissible to do what you want to do. (Now, if C had type inference...)
  - uecker 3y ago
    I am not sure I agree. What is allowed by the typing rules should always be clear. What may not always be clear is whether you statically get an error during compilation or only a run-time error. But considering that we now randomly get silent miscompilation which may or may not cause a run-time problem, if you cast a void* to the wrong type, I think this is a clear improvement.

by injuly 3y ago

nxobject 3y ago

Here is another way in which this is a little patch-like. The author observes that: (a) it is desired that _Var(T)* and void* be compatible; (b) however. pointers-to-T for different T are not guaranteed to be compatible in general, as a consequence, it is NOT guaranteed that _Var(T)* is compatible with T*, which is a theoretical wart worthy of C++. I can see it becoming especially annoying if you’re trying to introduce _Var(T) polymorphism into a code base that currently uses preprocessor macros that textually substitute types. Perhaps the better solution would be forgo giving void* any special status whatsoever. However, that means that this type of polymorphism can’t be implemented using void* as a polyfill.

uecker 3y ago

I don't think this is a deficiency, but an inherent property of powerful type systems. If you make them very expressive, then you can not have full type checking at compile time. On the other hand, if you restrict them so that you do full static type checking, than they are very limited.

nxobject 3y ago
It's a natural limit – but it doesn't make it easy to figure out in advance when it is/isn't permissible to do what you want to do. (Now, if C had type inference...)
- uecker 3y ago
  I am not sure I agree. What is allowed by the typing rules should always be clear. What may not always be clear is whether you statically get an error during compilation or only a run-time error. But considering that we now randomly get silent miscompilation which may or may not cause a run-time problem, if you cast a void* to the wrong type, I think this is a clear improvement.