Right. When I say “statically link” here, I really mean “put the .dylib for the library into the app bundle”. That’s what happens with Swift today. It can be important to share that code between apps and appex’s for example.
-Chris > On Jan 10, 2018, at 5:02 PM, Wallacy <walla...@gmail.com> wrote: > > If I understand this correctly. This is exactly the same argument in favor to > maintain the ABI unstable and always bundle the standard library and the > runtime with the app. > > Another alternative is, not only, separate the standard library on small > pieces, but also dynamic link this specific version of this piece and keep > all versions on the SO. (I think the Microsoft did something similar to this) > > On Linux the package manager probably will handle this very well like any > other library. > > Even 100 versions in the same SO will not consume enough space to bother > anyone. > > > Em qua, 10 de jan de 2018 às 17:04, Hooman Mehr via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> escreveu: > Excellent Idea! > > I am all for this. It shouldn’t be too complicated to add a second implicit > import and only code that is actually using this stuff will have increased > code size. > > > On Jan 9, 2018, at 10:29 PM, Chris Lattner via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > > Disclaimer: I’m reordering your comments below to suit my nefarious > > purposes: :-) > > > > On Jan 9, 2018, at 3:48 PM, Ben Cohen <ben_co...@apple.com > > <mailto:ben_co...@apple.com>> wrote: > >>> More to the point though, this seems like an implementation detail of > >>> Mirrors. What is the plan for Mirrors + ABI stability? > >>> > >> > >> Absent a proposal to change them to something better (and I’m not aware of > >> one pending), the plan is they are what they are, at least the public API > >> of Swift.Mirror. I would guess this whole area is a candidate to be > >> overhauled significantly at some point in the post-Swift 5 future with > >> some more fully-fledged reflection system, but there is little chance of > >> this happening before ABI stability, and interim tinkering doesn’t seem > >> worthwhile to me. > > > > Ok, I understand that (among all the other things going on that are clearly > > more important) revamping this is probably not the highest priority thing > > to do. That said, it would be really unfortunate to carry around these > > “suboptimal” APIs forever, particularly given how marginal they are (as in, > > not widely used). I’m sure that there are other examples beyond these that > > are similarly unfortunate. > > > > Given that, I have a meta question for you: have you considered an approach > > where you take the Swift standard library and split it into two conceptual > > pieces: > > > > 1) The "ABI stable” subset of the library that gets burned into the OS. > > 2) The “ABI unstable” subset, which gets statically linked into apps, just > > like the Swift 4 library used to? > > > > Given that “import Swift” is implicit anyway, you could just have the > > compiler implicitly import *both* of these modules. > > > > > > The point of doing this is that it gives you a very general and low > > friction way to handle compatibility gunk. In addition to putting obscure > > stuff like Mirror and “DictionaryLiteral” into this (without breaking > > source code!) you now get the ability to put the various deprecated > > forwarding functions in this module as well, avoiding them becoming part of > > the ABI. > > > > The nice thing about this is that only people who use these things would > > have to pay the cost, and you can directly message this by deprecating all > > the stuff in it. Think about it as an overlay for the Swift standard > > library :-) > > > >>> +1 for renaming it to something that isn’t super confusing, but +100 for > >>> removing it outright. > >>> > >>> Rationale: if we didn’t have this functionality in the stdlib today, we > >>> would not consider adding it. It doesn’t meet the bar we’ve set for what > >>> is in the standard library. It only exists there by historical accident. > >>> The Mirror API was not carefully considered. > >>> > >> > >> Personally, I feel like this argument for removal as past its use-by date. > >> It was a good reason for Swift 3, tenuous for 4 and should be ruled out > >> for 5, since the source stability bar has been raised since. Like I said, > >> IMO the criteria should now be “active harm”. I also don’t think searches > >> of GitHub etc are sufficient justification, except when combined with the > >> active-harm argument. I also don’t think the origin story of the type – > >> whether accidental or intentional – is relevant to the decision of what to > >> do with it now. It exists and people can legitimately use it for their own > >> purposes independent of mirrors. > > > > I’m generally in agreement with you, but in this specific case, I seriously > > doubt people are using this. All rules are malleable in the right > > circumstances. > > > > More importantly though, if we had a meta design that allowed to gracefully > > phase this sort of thing out (without it becoming part of ABI under any > > name) there becomes very little cost to leaving it around in the “abi > > unstable” library for…. ever if need be. Given that, I would have much > > less objection to keeping it around. > > > > -Chris > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
