Amsterdam
I write code.
Comment by ~sircmpwn on ~sircmpwn/hare-ev
REPORTED
RESOLVED CLOSEDComment by ~sircmpwn on ~sircmpwn/hare-ev
REPORTED
RESOLVED CLOSEDTicket created by ~sircmpwn on ~sircmpwn/hare-ev
Comment by ~sircmpwn on ~sircmpwn/hare
Nah.
Ticket created by ~sircmpwn on ~sircmpwn/hare
Comment by ~sircmpwn on ~sircmpwn/meta.sr.ht
Read the sidebar on the bug tracker, the part under "🛑 🛑 🛑 READ BEFORE FILING YOUR TICKET 🛑 🛑 🛑"
Comment by ~sircmpwn on ~sircmpwn/meta.sr.ht
REPORTED
RESOLVED INVALIDComment by ~sircmpwn on ~sircmpwn/hare
Perhaps, but a different solution which is not substantially more complex does not immediately suggest itself to me, and I am pleased with declaration-site inlining rather than call-site.
Comment by ~sircmpwn on ~sircmpwn/hare
Have thought about it but I'm not a huge fan of call-site inline, particularly considering that if any exported function can be inlined you have to stick the entire function body for all exported functions into the typedefs. And if they call any static functions... well at that point the typedefs become irrelevant and you have to do whole-module compilation every time. Or we have to implement LTO for qbe.
Comment by ~sircmpwn on ~sircmpwn/hare
having the hash depend on the context it's declared in is pretty weird, and I feel like it's probably a bad idea.
Hashes already depend on the context it's declared in: the relevant module scope.
The hash could be
hash(namespace + function name + serial number)
where serial number is assigned from 0 and increments for each type defined in a given function. I don't think the spec needs to be updated for this (at least not beyond allowing types to be defined in functions) because the means of establishing the type hash is implementation defined.I'm generally just not a fan of allowing in-scope bindings to have a type which is out of scope, and thus can't be referenced. Similar to why we require that the types of exported declarations also be exported (it simplifies the implementation ofc, but even when not taking implementation complexity into account it's still the right thing to do).
We should indeed prevent types from escaping their scope.