Ok, I could get behind that. Especially if we get factory initializers on
protocols…
Thanks,
Jon
> On Jan 23, 2017, at 5:57 PM, Karl Wagner wrote:
>
>
>> On 24 Jan 2017, at 01:13, Jonathan Hull via swift-evolution
>> wrote:
>>
>> Have we considered allowing a struct/class/enum to have the
> On 24 Jan 2017, at 01:13, Jonathan Hull via swift-evolution
> wrote:
>
> Have we considered allowing a struct/class/enum to have the same name as a
> protocol as long as it conforms to the protocol? Type declarations would
> have to always mean the protocol (which includes the concrete typ
Moreover, how would you extend the protocol?
On Mon, Jan 23, 2017 at 19:51 Xiaodi Wu wrote:
> No, I don't think so. How would you declare a variable of type X, meaning
> the protocol?
> On Mon, Jan 23, 2017 at 19:49 Jonathan Hull wrote:
>
> I agree with your point on classes, so maybe just value
No, I don't think so. How would you declare a variable of type X, meaning
the protocol?
On Mon, Jan 23, 2017 at 19:49 Jonathan Hull wrote:
> I agree with your point on classes, so maybe just value types would be
> allowed to do it (I have only wanted it for structs myself). I think I
> answered
I agree with your point on classes, so maybe just value types would be allowed
to do it (I have only wanted it for structs myself). I think I answered your
comment about distinguishing between existential and struct X if you re-read my
original message.
Thanks,
Jon
> On Jan 23, 2017, at 5:10
This would get very confusing, as it would be impossible for a class to
distinguish conforming to protocol X vs. inheriting from base class X, or
else we would have to change the spelling for that as well. Moreover, you
would have no way of distinguishing the existential X from the struct X. I
see
Have we considered allowing a struct/class/enum to have the same name as a
protocol as long as it conforms to the protocol? Type declarations would have
to always mean the protocol (which includes the concrete type as well). Static
functions would always apply to the concrete type.
Seems like
