Currently the message is the same but it's definitely reasonable to use a tailored one for cases like this. Please share if you have something in mind already.
Late to reviewing this proposal; I'd put it off as there were modifications upthread for clarity in flight, and then the time got away from me! I agree that the proposal is sensible, but I do have some quite serious concerns about the understandability of the text:
To start, I'll point out again that I still think @jrose's formulation of the principle in the pitch phase is the clearest explanation of this feature:
I would be strongly in favor of incorporating that text or some version of it explicitly in the proposal, not in the Introduction section where it's currently been worked in but rather as part of the proposed solution—even if it's desired for any future expansion to be put through the Evolution process separately (that can be spelled out too).
As it is, the text still emphasizes that the proposal aims to allow the return of different types, when really (as @jrose clarifies above so elegantly) it is just expanding the compiler's understanding of when code will in fact return the same type. I think @Jon_Shier's immediate impression that this proposal "violate[s] the single return type rule" is emblematic of how readers will misunderstand the proposal text without digging through this forum, and I'm concerned what that will do to long-term understanding of what we are setting out to do.
I also have concerns about the terminology: while it's technically true that we can always clarify our terms ("in this text, when I write x, I mean y"), I think it's a barrier to reader understanding to define something spelled with if #availability as an "unconditional availability." The term directly contradicts what the spelling tells us, namely that it is a condition about availability. What the author must mean here is either (1) that there are no other conditions but availability (i.e., no dynamic conditions), and/or (2) that within that conditional availability clause the code unconditionally returns the same type.
I will say that the Detailed design section in the proposal does a very nice job of closely tracking how someone might think about how to implement the feature and its exact proposed limits. However, because the text describes what's conditional as unconditional and it explains its rules about returning the same type per execution as an expansion to allow returning different types, it is very difficult for the reader to reach an understanding of why the feature is designed the way it is. One consequence is that readers won't grasp which parts of the rules and limitations laid out are inherent to the principle above and which are subject to future expansion due to (possibly temporary) implementation limits.
Anyway, concerns about the expository choices here aside, I think the expansion is a sensible one and the implementation limits are reasonable as-is. I think this is a very sensible improvement that fits with the overall feel and direction of Swift.
6 Likes
Thank you everyone for helping review this proposal! The Language Working Group has decided to accept this proposal.
2 Likes