> On Jan 9, 2018, at 11:48 AM, Chris Lattner via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>> IMO that isn’t a question we should be asking any more except in cases where
>> an existing implementation is causing active harm. Which, confusing name
>> aside, this type isn’t (aside from API sprawl I guess).
>
> It directly impacts code size for applications of swift that use the standard
> library as a standard library, e.g. a raspberry pi dev situation.
I’m not arguing that we should have profligate bloat in the Standard library,
but I feel that if we are seriously talking about scenarios where we want a
super-svelt Standard library for particular use-cases where code size and other
factors are a major concern, then I think that discussion goes well beyond just
cutting out APIs like Mirrors. Depending on the domain, other parts of the
Standard library seem like prime candidates to jettison as they may not carry
their weight *in those contexts*, even if those APIs are well-used in others.
In other words, we have various knobs we can pull here in this design space,
and the needs of Swift in different domains may be slightly different to be
worth exploring different options where appropriate. That’s not to say that
the ideas you are putting forth don’t have merit, but I think there is a danger
with lumping all of this up with the discussion about ABI stability in Swift 5.
More generally, I do think the idea of possibly carving up the Standard
Library into layers is a possible useful design idiom when considering Swift
being used in different contexts with different requirements/needs/constraints,
but an exploration of that idea doesn’t have to be tied to ABI stability.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
