Regards (From mobile)
> On Jul 21, 2016, at 9:20 AM, Robert Widmann via swift-evolution > <[email protected]> wrote: > > > > ~Robert Widmann > > 2016/07/21 0:13、Pyry Jahkola via swift-evolution <[email protected]> > のメッセージ: > >> >>>> On 21 Jul 2016, at 09:51, Robert Widmann via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> On Jul 20, 2016, at 9:37 PM, Félix Cloutier via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> The problem is that by specifying "import Foo using (Baz)", I get nothing >>>> else from Foo. If I only want to exclude one conflicting name, I would >>>> have: >>>> >>>>> import Foo >>>>> import Bar hiding (Baz) >>>> >>>> In case of a conflict, my "internal monologue" is more like "take Baz from >>>> Foo" than "don't take Baz from Bar". >>>> >>> >>> How else would you resolve an ambiguity than by selecting the appropriate >>> declaration and hiding the others? Swift’s semantic analysis cannot read >>> your mind, and neither can your (or mine) proposal for renaming syntax - in >>> that you still have to import both modules either way. You may as well be >>> explicit about which name you’re actually using and which ones you’re >>> actually hiding, eh? >> >> Simple! You don't need to hide the others if we enforce a rule that >> explicitly mentioning one in the current file imports that name as a >> fileprivate identifier which shadows the ones not explicitly mentioned: > > What you're describing is making a distinction between an open module and an > imported module and is both additive and out of scope for this particular > proposal. We didn't want to touch module re-exports until that proposal came > up later. This is a fantastic idea that we have plans to incorporate in > there nonetheless. This distinction is far more powerful than our current > approach of just opening every module that gets imported into the top level > namespace. > But it is a very limiting approach as has been seen in other languages and described here... designing a good system is as much about what it does today as what it will allow tomorrow and at what cost. Addressing the needs of today in a carpe diem fashion is an approach that works well when u are unsure if there will ever be a tomorrow, not for building the foundations of a legacy. To quote someone smarter "today's solutions are tomorrow's problems". >> >> import A using (X) >> import B // also exports X which gets shadowed by A.X >> import C // also exports X which gets shadowed by A.X >> >> assert(X.self == A.X.self) >> assert(X.self != B.X.self) >> assert(X.self != C.X.self) >> >> import D using (X) >> // error: invalid redeclaration of 'X' >> // note: previously declared here: 'import A using (X)' >> >> typealias X = Int >> // error: invalid redeclaration of 'X' >> // note: previously declared here: 'import A using (X)' >> >> That would go nicely hand-in-hand with the idea that explicitly importing a >> module with a qualified name brings in the name of that module to the >> current file's scope: >> >> import A // ok, unqualified import keeps A as a second-class >> identifier >> import B as B // ok, qualified import makes B a first-class identifier >> in file scope >> >> typealias A = Int // ok, shadows the module name A >> >> typealias B = Int >> // error: invalid redeclaration of 'Bar' >> // note: previously declared here: 'import Bar as Bar' >> >> Couldn't we find a synthesis with both the explicit qualification of modules >> and the explicit selection of imported names? I would strongly support that. >> >> — Pyry >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
