> I would argue that a successful addition to the standard library *must* have
> such additional justification about why it needs built-in support. If it's
> already in use as a third-party library, and you're arguing that the
> third-party design is already quite satisfactory and there's no built-in
> support required, then that's fundamentally an argument that it *doesn't*
> need to be in the standard library.
What? That doesn’t make any sense at all. I’ve written this proposal to
get a very popular and useful type into the standard library exactly because
it’s so popular and useful. It’s so popular and useful, in fact, that users are
running into issues getting all of the third-party implementations to play well
together. I’ll be adding more to the proposal about the general usefulness of
the Result type tomorrow, but it has often been said on this mailing list that
one of the ways a type can become part of the standard library is by becoming
popular in the community. My assertion is that Result has reached that point
and so needs consideration for the benefit of not only all current users of the
type, but the community in general.
I could also be confused about what you mean about “built-in” support,
or the types of things you’d think a standard library Result type should do
that isn’t in the proposal. In that case, could you be much more specific about
what additions you think it needs?
Jon
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
