todo.sr.ht

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.

#704 Consider adding @inline fn ... 10 days ago

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.

#88 Allow type and constant declarations in function bodies 13 days ago

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.