How about:
enums: @frozen -> @frozen(contents)
inlineable: @frozen(contents)
abi-public: @frozen
and maybe even...
structs: @fixed_contents -> @frozen(contents)
doesn’t that inhibit optimization opportunities as much as it could help? now the library compiler can’t optimize across foo() and bar(), even though the client can now optimize across wiz(). You’ve gotten rid of one boundary but introduced two.
y’all are overthinking this. there will be no good existing term for this because we’re introducing a new concept that’s native to complicated compilers like the swift compiler. (no more just shoving all the frozen stuff into a .h file). better to pick a term that’s simple and easy to remember, but meaningless, so we can teach users the correct meaning, instead of hoping it just implies something close enough. i think @frozen is perfect for that
Yes, isn’t that what you asked about?
your reply wasn't really clear if it was a good thing or a bad thing lol
Concepts that require teaching can nonetheless be designed to be easier or harder to learn. Names matter, and meaningless names are contrary to the design direction of Swift.
a meaningless name is still better than a misleading name, or a name that overlaps with unreleated usage in the same domain
I would argue that they are all shades of bad.
%rip
The proposal mentiones that the closest concept in other languages is the C’s extern something something… Can’t we borrow that term and introduce @externed?
externed sounds painful 
1 Like
One of the reasons I didn't mention before for why I like @exposed, actually, is because it has a similar sound to "extern" and so it's easy for my C-trained-mind to attach the right meaning to it. But I think having a real English word (with the right meaning) for the attribute is preferable to another language's keyword for the attribute.
1 Like
why not just “visible” means the same thing and has less weird connotations
We cannot call it @frozen precisely because that would overlap with usage in the same domain. Xiaodi's explanation of this seems quite good to me.
@abiPublic is not a generalization of @frozen to functions, but more like a kind of augment to access control. It's an augment, though, and not just a new level of access because conceptually it could absolutely be extended to non-internal declarations — we would just need to solve some technical problems that we're not proposing to solve right away. @hidden public seems to get this backwards, because the declaration is not public in any of the normal semantic senses of the language.
It is certainly true that inlining an @inlinable function can hurt performance because the un-inlined function can be better optimized as a whole. Actually, that's always true of inlining — inlining heuristics are very much a dark art. But I think that part of the conversation here is off-topic, because it is undoubtedly true that inlining is sometimes profitable, and we have to have a mechanism for allowing that.
I'd like to ask the thread to focus on the naming discussion. Right now, I'm not seeing much of a consensus here, which will put the Core Team in the difficult position of just deciding it ourselves. Several spellings have been suggested. If you have a better suggestion, that's great, and you should absolutely post it; but please also provide some feedback on the things other people have proposed. The revised proposal is @inlineAvailable, but there's only been a small amount of discussion about that name. @exposed seems like a workable counter-proposal; what do people think about it? And so on.
2 Likes
i only talk about the performance aspect of it because some people were proposing @optimizable which could have all sorts of unintended consequences
i still say @visible is the way to go. in fact, i think putting it as a qualifier on the access control label is an elegant way to approach this
public(visible)
internal(visible)
internal(set, visible)
I'm aware that they are not exactly the same. Each type/member can be "frozen" in different (but analogous) ways. If we insist on every keyword being so very literal, we will end up with a keyword soup - @(non)frozen for enums, @inlineable for functions, @fixed_contents for structs, and @abiPublic as a dependent but slightly-different concept. I've seen several threads where members of the core team agree that it would be nice to simplify this list, if possible.
My argument is that I shouldn't be writing specific compiler optimisations in to my code. I should focus on which commitments I make about the type/member (read: how much flexibility I have to make edits without breaking source or ABI), and the compiler should worry about translating that in to specific optimisations like inlining.
I think "frozen" (as a word) nicely captures the idea of making future commitments about the availablility/shape of a type or member. It's a level of abstraction but it's worth overloading the name a little bit to reduce the surface area of these attributes IMO.
Perhaps “@linkable” or something in that vicinity?
Again, the analogue of @frozen here is @inlineable, not @inlineAvailable: it says not only that the entity will always exist, but that it will be implemented in a particular way.
Sure - but then - what if we changed that, and made @frozen refer to the availability, not the contents? In favour of a unifying concept?
I think almost nobody gets to use frozen/non-frozen enums yet anyway, after the proposal was amended...
The existence of that analogue means that we really can’t use the name for something else, even if we choose to spell the analogue differently.