4 ms·
As I posted before the outage, I don't think leaking un-exported elements is actually that broken either -- Haskell gets by fine with it (you can omit the type
by rfw 13y ago
As I posted before the outage, I don't think leaking un-exported elements is actually that broken either -- Haskell gets by fine with it (you can omit the type and its constructor in the module export list and have types "leak" into the code importing said module). It can be a useful way to keep types opaque and not allow users to construct instances directly.
The actual issue, in my opinion, is the weird behavior of the reflect package which allegedly cannot reflect on the leaked element despite its members being publicly accessible anyway.
- DrJokepu 13y agoAuthor here. What I’ve written regarding the reflect behaviour isn’t entirely true and I should probably update the article to reflect that. It’s possible to get (but not set) the value of unexported fields as long as they are of a built in type (e.g. int). What’s not possible is to get access to unexported fields as empty interfaces, which means you cannot type assert them to structs or other types. This seems like an arbitrary limitation (although I’m sure there is a reason for it) and somewhat limits the usefulness of the reflect package.