> On May 8, 2017, at 4:02 PM, Tony Allevato <tony.allev...@gmail.com> wrote:
>
> On Sat, May 6, 2017 at 4:17 PM Chris Lattner <clatt...@nondot.org
> <mailto:clatt...@nondot.org>> wrote:
> On May 5, 2017, at 11:33 AM, Tony Allevato via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>
>>
>> Can the opt-in conformance be declared in an extension? If so, can the
>> extension be in a different module than the original declaration? If so, do
>> you intend any restrictions, such as requiring all members of the type
>> declared in a different module to be public? My initial thought is that
>> this should be possible as long as all members are visible.
>>
>> Declaring the conformance in an extension in the same module should
>> definitely be allowed;
>
> Please follow the precedent of the Codable proposal as closely as possible.
> If you’d like this to be successful for Swift 4, you should look to scope it
> as narrowly as possible. Because it is additive (with opt-in), it can always
> be extended in the future.
>
>> I believe this would currently be the only way to support conditional
>> conformances (such as the `Optional: Hashable where Wrapped: Hashable`
>> example in the updated draft), without requiring deeper syntactic changes.
>
> This proposal doesn’t need to cover all cases, since it is just sugaring a
> (very common) situation. Conditional conformances to Hashable could be
> written manually.
>
>> I'm less sure about conformances being added in other modules,
>
> It is a bad idea, it would break resilience of the extended type.
>
>> But after writing this all out, I'm inclined to agree that I'd rather see
>> structs/enums make it into Swift 4 even if it meant pushing classes to Swift
>> 4+x.
>
> Agreed, keep it narrow to start with.
>
> Also, I don’t know how the rest of the core team feels about this, but I
> suspect that they will be reticent to take an additive proposal at this late
> point in the schedule, unless someone is willing to step up to provide an
> implementation.
>
> That someone is me :) I have a branch where it's working for enums (modulo
> some weirdness I need to fix after rebasing a two-month-old state), and
> adapting that logic to structs should hopefully be straightforward after
> that. Going with the more narrowly-scoped proposal and making conformances
> explicit simplifies the implementation a great deal as well (I was previously
> blocked with recursive types when it was implicit).
>
> Thanks for the feedback—after consideration, I've pulled classes out of the
> proposal completely (even non-final) and mentioned the other limitations so
> we'd have a record of what was discussed in this thread.
>
> I've created a PR for the proposal text, in the event that the core team is
> interested in moving this forward:
> https://github.com/apple/swift-evolution/pull/706
> <https://github.com/apple/swift-evolution/pull/706>
Thanks for continuing to push this forward Tony! The current proposal looks
like the right approach for getting this into Swift 4.
I only have one question which I will present with an example:
protocol Foo: Equatable {}
protocol Bar: Hashable {}
struct FooType: Foo {}
struct BarType: Bar {}
Do FooType and BarType receive synthesis?
>
>
>
> -Chris
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
