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

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] namespacing protocols to other types

Well again I don’t think we should disallow capturing the outer generic type parameter just because you cannot use the protocol inside the outer type atm., you still can add a type-eraser. To be honest such usage of the existential is not even a requirement for the outer type. On there other

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

> On 28. Dec 2017, at 12:34, Adrian Zubarev > wrote: > > I disagree with some of your points. Do begin with, I don’t think we should > disallow capturing the generic type parameter, because I think there might be > a good way to prevent parameterization of

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

I disagree with some of your points. Do begin with, I don’t think we should disallow capturing the generic type parameter, because I think there might be a good way to prevent parameterization of nested protocols. To me this only feels like a natural consequence of nesting protocols anyways.

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

Yeah I wrote that proposal. I eventually stripped it down to just disallow all capturing, but it was still not selected by the core team for review ¯\_(ツ)_/¯ As for capturing semantics, once you start working through use-cases, it’s becomes clear that it's going to require generalised

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

Amen. This seems like an appropriate step towards better name-spacing, and it’s one we have sorely missed on one manor project at work. We maintain a framework that wraps our various web APIs with convenience methods and data model types. Since the APIs are versioned, we have nested most

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

vv On Sun, Dec 24, 2017 at 11:36 PM, Howard Lovatt wrote: > I would say yes they are different for the example. Definitely something I > miss is nesting types to given a seperate namespace. > > -- Howard. > > > On 24 Dec 2017, at 9:56 pm, Slava Pestov via

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

I would say yes they are different for the example. Definitely something I miss is nesting types to given a seperate namespace. -- Howard. > On 24 Dec 2017, at 9:56 pm, Slava Pestov via swift-evolution > wrote: > > There was a proposal to allow protocols to be

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

There was a proposal to allow protocols to be nested inside types at one point but it didn’t move forward. Basically, if the outer type is a non-generic class, struct or enum, there’s no conceptual difficulty at all. If the outer type is a generic type or another protocol, you have a problem

[swift-evolution] namespacing protocols to other types

is there a reason why it’s not allowed to nest a protocol declaration inside another type? ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution