> On 2 Jan 2018, at 13:06, Toni Suter wrote:
>
> Yes, I think I agree with you. Maybe we are missing something, but I don't
> see a reason why declaring a property with the same name and a different type
> should be allowed in the 1. scenario.
>
> So maybe you should file a bug in JIRA, after a
Yes, I think I agree with you. Maybe we are missing something, but I don't
see a reason why declaring a property with the same name and a different type
should be allowed in the 1. scenario.
So maybe you should file a bug in JIRA, after all.
Best regards,
Toni
> Am 02.01.2018 um 13:56 schrieb Ma
> On 2 Jan 2018, at 09:12, Toni Suter wrote:
>
>
> You can only 'overload' properties that are inherited from a protocol
> extension.
>
> protocol P {}
> extension P {
> static var x: Int { return 2 }
> }
> struct S: P {
> static var x = ""
> }
>
> I am not exactly sure why this is
Hi Marc,
>> The second class defines a static property that looks like it is
>> 'overriding' the static property from
>> the protocol extension, but since the types don't match (String vs.
>> String?), it sort of 'overloads'
>> the property (similar to function overloading). Nevertheless, the cl
> On 1 Jan 2018, at 20:40, Toni Suter wrote:
>
> Hi Marc,
>
> There are several subtleties here, but I think the compiler is actually doing
> the right thing.
>
Hi Toni,
Thanks for your detailed response.
[..]
> The second class defines a static property that looks like it is 'overriding'
Rest of message - hit send by mistake.
The problem is that it is really easy to make the mistake you made. There have
been a number of suggestions on Swift Evolution to add key words so that
diagnostics can be improved. For example:
protocol P {
func m()
}
extension P {
Unfortunately the error messages you get with protocols are limited :). The
compiler is doing the right thing, no bug. The problem is that it is really
easy to mak
-- Howard.
> On 1 Jan 2018, at 3:40 pm, Toni Suter via swift-users
> wrote:
>
> Hi Marc,
>
> There are several subtleties here
Hi Marc,
There are several subtleties here, but I think the compiler is actually doing
the right thing.
The second class defines a static property that looks like it is 'overriding'
the static property from
the protocol extension, but since the types don't match (String vs. String?),
it sort o
Hi,
I hope everybody had a great New Year celebration.
I was tracking down a weird bug in my Swift code today. A property defined in a
class in order to conform to a protocol was not being seen. A protocol
extension provided a default value of `nil` for this property, so I knew where
it was co
