On Feb 22, 2017, at 6:32 AM, John McCall <[email protected]> wrote: >> >> 3) Third, your enum needs to be declared fragile in order to allow clients >> to enumerate their cases specifically. >> >> The third step (having to mark your enum fragile, however it is spelled) is >> the biggest sign that you’re opting into a commitment that you should think >> really hard about. If folks don’t know that this is a big API commitment, >> then we have bigger problems. > > You're imagining somebody adding a throws annotation because their function > itself has one or two explicit throw sites.
I was trying to imagine what the “bad thing” was that you were imagining, I guess I missed the mark :) > In reality, it's probably because they're calling some other function that > can throw. The low-impedence path in that case is to declare that you throw > whatever that function throws; this is why people talk about exceptions > encoding your library's dependency tree. Yeah, I’ve totally seen that in Java and other languages, so I can see your concern. I think that that concern is completely addressed by: 1) Only allow one thrown type. 2) Never add T | U | V syntax for anonymous enums. Both of these seem strongly motivated by other design points in swift, so I took those for granted. With the two of them together, Swift would seriously reduce the odds of your "bad thing” from happening, because people who have to write out new enum types to encode their dependency tree. >> AFAICT, the cost of this API is only a “li rN, 0” in the normal path. > > If you're willing to give up on a no-malloc guarantee, even if the fact of > resilience, yes, this and similar techniques would work. I'm not sure that > all "deep systems" code is quite that deep. I’m not claiming that all “deep systems” code (whatever that means) is quite "that deep", only that an interesting communities who consider themselves purveyors of systems code also care about controlling allocations for a variety of reasons. The sort of systems code I’m imagining doesn’t care about resilience at all. They generally have a closed world assumption anyway. -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
