I really like this idea of scoped import, but I’m not sure it’s part of anything supported widely. I was about to suggest ‘namespaces’ but that’s not a thing in swift.
On Nov 9, 2017, 17:06 -0500, Rod Brown <rodney.bro...@icloud.com>, wrote: > > > On 7 Nov 2017, at 6:24 am, Tony Parker via swift-evolution > > <swift-evolution@swift.org> wrote: > > > > Hi Florent, > > > > We definitely thought about this while designing the set of types with the > > Codable proposals. > > > > One serious concern was just how much API surface area there already is > > with Codable. If we open up the internal classes as well, we risk confusing > > the majority of people who are just adopting Codable with APIs that are > > intended only for the minority of people who are trying to create their own > > custom encoders and decoders. > > > > Any thoughts on how to mitigate this? > > > > - Tony > > I’ve been curious for some time about if we can do something about an opt-in > import in Swift? > > For example, currently UIGestureRecognizer in UIKit has “subclass only” > methods that are protected and opt in. Importing UIKit itself doesn’t bring > it in, and instead you need to specifically import > UIKit.UIGestureRecognizerSubclass. > > I realise this is a standalone case, but I’m wondering whether we can > generalise this into something we can propose, to actively support nested > scopes in the same way? > > This would lend well to disclosing the internals like this. It would avoid > users jumping straight for the internal types because they wouldn’t be there > with “import Foundation” - it would require something eg “import > Foundation.xyz”. > > Was this part of an earlier discussion of modules etc? > > - Rod > > > > > > On Nov 3, 2017, at 9:58 AM, Florent Vilmart via swift-evolution > > > <swift-evolution@swift.org> wrote: > > > > > > At Swift Summit, we discussed with Joe and Jordan about opening up the > > > Encoder/Decoder classes in order to make the work of an encoder designer > > > easier. > > > > > > As I was working on an API project, I found myself into the situation of > > > needing to tweak so slightly the encoding strategy this required a full > > > copy/paste of the JSONEncoder.swift file and playing with the internals. > > > I also wanted to implement a simple QueryStringEncoder/Decoder that would > > > properly encode / decode a query string. > > > > > > The internally defined classes are proven a very powerful tool of > > > reflection as well, being able to collect / untransform a series of > > > containers safely into a strongly typed swift object. > > > > > > The pitch: > > > > > > - Keep JSONEncoder / JSONDecoder as 'proxies' to encoding to Data > > > - Make _JSONEncoder / _JSONDecoder open classes > > > - Mark public all container implementations of UnkeyedEncodingContainers > > > etc... > > > - Find a good naming for the _JSONEncoder and _JSONDecoder, that doesn't > > > conflict with JSONEncoder / JSONDecoder but also denotes they conform to > > > Encoder. > > > > > > Opening those API's isn't for the general Codable implementation, the > > > JSONEncoder/JSONDecoder should stay as-is but it's intended to reduce the > > > amount of boiler plate one would need to implement in order to provide > > > different serialization mechanism / strategy. > > > > > > > > > _______________________________________________ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
