Re: [swift-evolution] namespacing protocols to other types

On Fri, Dec 29, 2017 at 11:20 PM, Eneko Alonso wrote: > Modules do more than that. For instance, if two imported modules provide a > type with the same name, you can distinguish (name-spacing) them by using > ModuleA.Thing vs ModuleB.Thing. > > In regards of Modules being

[swift-evolution] extension of AnyObject

Hi All. I just discovered that you can’t write an extension on AnyObject. What’s the reasoning behind this? I’m trying to write my own version of KeyValueObserving, and it would be really nice to be able to write self.observe(someObject, keyPath) { blah de blah } from

Re: [swift-evolution] namespacing protocols to other types

Modules do more than that. For instance, if two imported modules provide a type with the same name, you can distinguish (name-spacing) them by using ModuleA.Thing vs ModuleB.Thing. In regards of Modules being intended to be shipped separately, that is incorrect. You might be thinking of

Re: [swift-evolution] namespacing protocols to other types

Modules in Swift are really designed for code that is intended to be shipped separately. as Jon found out modules are pretty heavyweight and introduce a lot of unwanted abstraction and complexity when all you want to do is write things in a namespace. (Also if you forgot, importing a module in

Re: [swift-evolution] namespacing protocols to other types

…all i wanted to do was write Thing:Namespace.Protocol On Thu, Dec 28, 2017 at 4:43 PM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > Well again I don’t think we should disallow capturing the outer generic > type parameter just because you cannot use the protocol

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

that’s why i keep saying we should separate human-facing encapsulation concepts from compiler-facing abi visibility concepts. i’ve always been advocating for something like internal(visible) fileprivate(visible) private(visible) in the same spelling we currently use for stuff like private(set).

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

I agree with the common theme that `@abiPublic` is weird. I imagine that not a lot of `@abiPublic` symbols actually want to be internal: they'll almost all be implementation details that really want to be `private` or `fileprivate` but that have to be `internal` to satisfy what (I believe) most