It's not impossible to gate protocols by availability, and it would in fact be easier for a new protocol like ExpressibleByTupleLiteral than @taylorswift's example because we'd be introducing the entire protocol as a new thing, rather than retroactively introducing new conformances of existing types to an existing protocol. Nonetheless, it seems unfortunate to me to subject features whose primary purpose is compile-time sugar to runtime availability constraints. As @Dave_Abrahams1 likes to say, the existence of a protocol ought to be justified by the kinds of programs you can write against the interface and guarantees a protocol gives you. By themselves, the literal protocols don't really give you much of an API contract to work with, and are of marginal use as generic constraints on their own. As such, from a blank slate they seem like poor candidates for protocols, even putting aside the runtime deployment issues.