A shortcut to pointer type inferencing #432
dmlloyd
started this conversation in
Design discussions
Replies: 1 comment
-
This seems like a reasonable approach to me as it would unblock @theresa-m's work without getting mired in changing the inference algorithm. The extra classes are a low cost and shouldn't have much effect on the final image's footprint |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
When I first mocked up the
CNative
API, I imagined I'd implement a very clever inference algorithm to allow pointer/pointee types to magically flow through the system despite generics erasure. But such an inference algorithm would be pretty difficult to implement correctly (and verify) in practice, and while I think it experimenting on this idea might be a fun way to spend a couple of months, I think that it's probably not the best use of time when other urgent matters are pressing and people are having problems today.Because of this I started trying to think of ways to shortcut having to develop a complex inference algorithm. What I've ended up with is modeling a solution whereby
ptr
is made non-final (perhaps abstract) and the generic pointer types are essentially manually reified. It's a bit ugly in some respects, but not unacceptably so IMO.Here's an example of what it would look like for
struct iovec
, a C type which is used pervasively in I/O code:The six new type definitions are boilerplate: in IntelliJ IDEA, I was able to create a live template to generate them. I don't love having to do that but it's a relatively low overhead way to emit what are likely to be the most common derived types for a given type. The naming convention is meant to most accurately mirror what the C syntax would be, e.g.
const_struct_iovec_ptr_const_ptr ≅ const struct iovec * const *
.We'd then have cast expressions like this:
The downside is that we'll have to introduce (and potentially load) a fairly large number of classes (as many as 5-10 extra classes for certain types). In addition, there would be little other than convention to prevent people from defining the same type more than one time (which is OK in terms of code correctness, but is potentially a bit ugly). The upside is that type safety should instantly improve significantly.
If this idea is popular, I'll plan on moving forward with it as soon as possible (probably immediately after the rename is complete).
Beta Was this translation helpful? Give feedback.
All reactions