Re: [swift-dev] Warning when "overriding" an extension method that's not in the protocol
> On Dec 31, 2015, at 3:15 PM, Jesse Rusak wrote:
>
> Hi Doug,
>
> I’ve been playing around with an implementation of the warning you referenced
> here:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001584.html
>
> Would it be helpful for me to take this on?
Yes, absolutely!
> If so, is there any detail in the radar assigned to you about what exactly
> should trigger such a warning?
> For example, I have it currently triggering whenever there’s a method with a
> matching name, ignoring parameter/return types; it’s not obvious to me how
> closely they should have to match, if at all, to trigger the warning.
I just realized that I wrote up a big discussion of a related-but-not-identical
warning. In either case, there is some kind of radar, and neither gives a lot
of detail.
In general: just matching on name alone feels like it might produce too many
false positives, but exactly matching parameter/return types feels like it
might miss cases where this warning would be important, so… I think it’s going
to come down to coming up with cases where you do/don’t want to see the warning
and tuning the warning to do the right thing. It might be that you want to do
some simplistic matching (perhaps akin to what lib/Sema/TypeCheckProtocol.cpp
does when inferring type witnesses) that ignores uses of associated types that
might have been deduced differently from what the user expected.
That leads to my #1 example I’d love to get a warning for, which is when you
intended to provide something to satisfy a protocol requirement, but you ended
up getting a default implementation:
struct MyGenerator {
mutating func next() -> Int? { return nil }
}
struct MyCollection : CollectionType {
typealias Index = Int
var startIndex: Int { return 0 }
var endIndex: Int { return 10 }
subscript (index: Int) -> Int {
return index
}
func generate() -> MyGenerator {
print("using MyGenerator")
return MyGenerator()
}
}
func foo(c: C) {
c.generate()
}
foo(MyCollection())
Note that there is no output from this program, although one would expect to
see “using MyGenerator”.
The root of the problem is annoying simple (I “forgot” to state that
MyGenerator conforms to GeneratorType). The result is that the implied
SequenceType conformance gets a default implementation of “generate” from a
protocol extension in the standard library (that produces default generator for
any SequenceType that is also a CollectionType). Our place to warn about this
is at the point where we decide to use a “generate” from a protocol extension
rather than the “generate” in the same “struct” that declares conformance to
CollectionType. Obviously, lots of bonus points if we could say why the
generate() in the struct wasn’t picked :)
That brings up another point about warnings: it’s useful to have a way to
suppress them. Let’s say we got a warning for my example above (huzzah!) but I
wanted to silence it. A fairly natural way to do so would be to move the
“generate” function I defined into a separate extension, so it’s away from
where we state conformance to CollectionType:
struct MyGenerator {
mutating func next() -> Int? { return nil }
}
struct MyCollection : CollectionType {
typealias Index = Int
var startIndex: Int { return 0 }
var endIndex: Int { return 10 }
subscript (index: Int) -> Int {
return index
}
}
extension MyCollection {
func generate() -> MyGenerator { // no warning
print("using MyGenerator")
return MyGenerator()
}
}
Effectively, we’re using the declaration of conformance to a protocol as
indicating user intent that the contents of this particular
definition/extension involve that conformance.
The actual warning you are talking about is very, very similar, and would
likely use most of the same logic. The part that differs is the trigger:
whenever one declares something within a type, perform a lookup in that type to
determine whether there are any similar members of extensions of one of the
protocols that type conforms to. You'll want to think about how to suppress the
warning when the user wants to.
- Doug
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
Re: [swift-dev] Warning when "overriding" an extension method that's not in the protocol
On Sat, Jan 2, 2016, at 11:39 AM, Douglas Gregor via swift-dev wrote:
>
>
>> On Dec 31, 2015, at 3:15 PM, Jesse Rusak wrote:
>>
>> Hi Doug,
>>
>> I’ve been playing around with an implementation of the warning you
>> referenced here:
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001584.html
>>
>> Would it be helpful for me to take this on?
>
> Yes, absolutely!
>
>> If so, is there any detail in the radar assigned to you about what
>> exactly should trigger such a warning? For example, I have it
>> currently triggering whenever there’s a method with a matching name,
>> ignoring parameter/return types; it’s not obvious to me how closely
>> they should have to match, if at all, to trigger the warning.
> I just realized that I wrote up a big discussion of a related-but-not-
> identical warning. In either case, there is some kind of radar, and
> neither gives a lot of detail.
>
> In general: just matching on name alone feels like it might produce
> too many false positives, but exactly matching parameter/return types
> feels like it might miss cases where this warning would be important,
> so… I think it’s going to come down to coming up with cases where you
> do/don’t want to see the warning and tuning the warning to do the
> right thing. It might be that you want to do some simplistic matching
> (perhaps akin to what lib/Sema/TypeCheckProtocol.cpp does when
> inferring type witnesses) that ignores uses of associated types that
> might have been deduced differently from what the user expected.
>
> That leads to my #1 example I’d love to get a warning for, which is
> when you intended to provide something to satisfy a protocol
> requirement, but you ended up getting a default implementation:
>
>> struct MyGenerator { mutating func next() -> Int? { return nil } }
>>
>> struct MyCollection : CollectionType { typealias Index = Int
>>
>> var startIndex: Int { return 0 } var endIndex: Int { return 10 }
>>
>> subscript (index: Int) -> Int { return index }
>>
>> func generate() -> MyGenerator { print("using MyGenerator")
>> return MyGenerator() } }
>>
>> func foo(c: C) { c.generate() }
>>
>> foo(MyCollection())
>
> Note that there is no output from this program, although one would
> expect to see “using MyGenerator”.
>
> The root of the problem is annoying simple (I “forgot” to state that
> MyGenerator conforms to GeneratorType). The result is that the implied
> SequenceType conformance gets a default implementation of “generate”
> from a protocol extension in the standard library (that produces
> default generator for any SequenceType that is also a CollectionType).
> Our place to warn about this is at the point where we decide to use a
> “generate” from a protocol extension rather than the “generate” in the
> same “struct” that declares conformance to CollectionType. Obviously,
> lots of bonus points if we could say why the generate() in the struct
> wasn’t picked :)
>
> That brings up another point about warnings: it’s useful to have a way
> to suppress them. Let’s say we got a warning for my example above
> (huzzah!) but I wanted to silence it. A fairly natural way to do so
> would be to move the “generate” function I defined into a separate
> extension, so it’s away from where we state conformance to
> CollectionType:
>
>
>> struct MyGenerator { mutating func next() -> Int? { return nil } }
>>
>> struct MyCollection : CollectionType { typealias Index = Int
>>
>> var startIndex: Int { return 0 } var endIndex: Int { return 10 }
>>
>> subscript (index: Int) -> Int { return index } }
>>
>> extension MyCollection { func generate() -> MyGenerator { // no
>> warning print("using MyGenerator") return MyGenerator() } }
>>
> Effectively, we’re using the declaration of conformance to a protocol
> as indicating user intent that the contents of this particular
> definition/extension involve that conformance.
This isn't going to work well for cases where the protocol declares a
property (with a default computed property impl) and a conforming type
attempts to use a stored property. Stored properties must be declared in
the initial type declaration, not in extensions. The only way to
suppress it then would be to suppress the warning in general for members
provided in the initial type declaration when the protocol conformance
is part of an extension (sort of the opposite of the suggested way of
suppressing warnings), and maybe that's fine, but it does mean that
there's no way to suppress the warning for a single stored property
without suppressing it for all stored properties.
> The actual warning you are talking about is very, very similar, and
> would likely use most of the same logic. The part that differs is the
> trigger: whenever one declares something within a type, perform a
> lookup in that type to determine whether there are any similar
> members of extensions of one of the protocols that type conforms to.
> You'll want to think about how to suppress the warning
Re: [swift-dev] Swift vim support
Incidentally, for a long time I've maintained my own vim Swift plugin at
https://github.com/kballard/vim-swift. It provides a bunch of features like
compiling and running the current file when you press ⌘R. It's not entirely
up-to-date yet (e.g. I haven't updated it to allow string literals inside of
string interpolations) but it works pretty well. It also doesn't have custom
indentation support (I'm using autoindent and smartindent), but it works pretty
well for most things except switch cases.
That said, I did recently stop using it in favor of the one in the Swift repo
for the simple reason that my plugin isn't compatible with .gyb files (my
plugin defines a complex nested syntax hierarchy, which allows it to detect a
lot of invalid syntax, but the gyb syntax can't work with that). I have been
thinking about switching back to mine for normal files and only using the Swift
repo one for .gyb files though.
In any case, I also support the notion of having an "official" plugin in its
own repo, and I would suggest that using something like mine as the base might
be nice.
-Kevin Ballard
On Thu, Dec 31, 2015, at 08:32 PM, Harlan Haskins via swift-dev wrote:
> I love vim and would love to see static analyzer and SPM-aware vim support.
> +1 from me.
>
> > On Dec 31, 2015, at 6:11 PM, Dmitri Gribenko via swift-dev
> > wrote:
> >
> > On Thu, Dec 31, 2015 at 10:09 PM, Keith Smiley via swift-dev
> > wrote:
> >> Hey all,
> >>
> >> When swift was open sourced a few of us noticed that there was some
> >> existing
> >> vim highlighting support[0]. While it sounds like what's there now hasn't
> >> been
> >> kept up to date for a while[1], that brought up the question if there could
> >> ever be a dedicated repository for vim support under the apple github
> >> organization.
> >
> > I'm using vim, and I would be interested in having strong vim support for
> > Swift.
> >
> > Dmitri
> >
> > --
> > main(i,j){for(i=2;;i++){for(j=2;j > (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
> > ___
> > swift-dev mailing list
> > swift-dev@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-dev
>
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
> Email had 1 attachment:
> + smime.p7s
> 2k (application/pkcs7-signature)
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
Re: [swift-dev] Warning when "overriding" an extension method that's not in the protocol
(CCing the list again as I believe you omitted it accidentally)
On Sat, Jan 2, 2016, at 10:10 PM, Douglas Gregor wrote:
> On Jan 2, 2016, at 6:58 PM, Kevin Ballard via swift-dev d...@swift.org> wrote:
>> On Sat, Jan 2, 2016, at 11:39 AM, Douglas Gregor via swift-dev wrote:
>>>
>>>
On Dec 31, 2015, at 3:15 PM, Jesse Rusak wrote:
Hi Doug,
I’ve been playing around with an implementation of the warning you
referenced here:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001584.html
Would it be helpful for me to take this on?
>>>
>>> Yes, absolutely!
>>>
If so, is there any detail in the radar assigned to you about what
exactly should trigger such a warning? For example, I have it
currently triggering whenever there’s a method with a matching
name, ignoring parameter/return types; it’s not obvious to me how
closely they should have to match, if at all, to trigger the
warning.
>>> I just realized that I wrote up a big discussion of a related-but-not-
>>> identical warning. In either case, there is some kind of radar, and
>>> neither gives a lot of detail.
>>>
>>> In general: just matching on name alone feels like it might produce
>>> too many false positives, but exactly matching parameter/return
>>> types feels like it might miss cases where this warning would be
>>> important, so… I think it’s going to come down to coming up with
>>> cases where you do/don’t want to see the warning and tuning the
>>> warning to do the right thing. It might be that you want to do some
>>> simplistic matching (perhaps akin to what
>>> lib/Sema/TypeCheckProtocol.cpp does when inferring type witnesses)
>>> that ignores uses of associated types that might have been deduced
>>> differently from what the user expected.
>>>
>>> That leads to my #1 example I’d love to get a warning for, which is
>>> when you intended to provide something to satisfy a protocol
>>> requirement, but you ended up getting a default implementation:
>>>
struct MyGenerator { mutating func next() -> Int? { return nil } }
struct MyCollection : CollectionType { typealias Index = Int
var startIndex: Int { return 0 } var endIndex: Int { return 10 }
subscript (index: Int) -> Int { return index }
func generate() -> MyGenerator { print("using MyGenerator")
return MyGenerator() } }
func foo(c: C) { c.generate() }
foo(MyCollection())
>>>
>>> Note that there is no output from this program, although one would
>>> expect to see “using MyGenerator”.
>>>
>>> The root of the problem is annoying simple (I “forgot” to state that
>>> MyGenerator conforms to GeneratorType). The result is that the
>>> implied SequenceType conformance gets a default implementation of
>>> “generate” from a protocol extension in the standard library (that
>>> produces default generator for any SequenceType that is also a
>>> CollectionType). Our place to warn about this is at the point where
>>> we decide to use a “generate” from a protocol extension rather than
>>> the “generate” in the same “struct” that declares conformance to
>>> CollectionType. Obviously, lots of bonus points if we could say why
>>> the generate() in the struct wasn’t picked :)
>>>
>>> That brings up another point about warnings: it’s useful to have a
>>> way to suppress them. Let’s say we got a warning for my example
>>> above (huzzah!) but I wanted to silence it. A fairly natural way to
>>> do so would be to move the “generate” function I defined into a
>>> separate extension, so it’s away from where we state conformance to
>>> CollectionType:
>>>
>>>
struct MyGenerator { mutating func next() -> Int? { return nil } }
struct MyCollection : CollectionType { typealias Index = Int
var startIndex: Int { return 0 } var endIndex: Int { return 10 }
subscript (index: Int) -> Int { return index } }
extension MyCollection { func generate() -> MyGenerator { // no
warning print("using MyGenerator") return MyGenerator() } }
>>> Effectively, we’re using the declaration of conformance to a
>>> protocol as indicating user intent that the contents of this
>>> particular definition/extension involve that conformance.
>>
>> This isn't going to work well for cases where the protocol declares a
>> property (with a default computed property impl) and a conforming
>> type attempts to use a stored property. Stored properties must be
>> declared in the initial type declaration, not in extensions.
>
> We've discussed a change to allow stored properties within extensions
> of the nominal type that occur in the same module, by if we don't get
> that (or we limit it somehow), you're right.
We did discuss that, but we haven't agreed on it yet (and last I
checked it seemed there was more support for limiting it just to
classes anyway).
>> The only way to suppress it then would be to suppress the warning in
>
Re: [swift-dev] Radar and bugs.swift.org
> On Dec 31, 2015, at 12:03 PM, Joe Groff via swift-dev > wrote: > > >> On Dec 31, 2015, at 11:47 AM, Keith Smiley via swift-dev >> wrote: >> >> Would it be worthwhile for the swift team if those of us who have created >> many swift related radars to copy them over to bugs.swift.org? > > Definitely. If you can spare the extra effort, we'd appreciate cross > references between the public and Radar bugs on Jira and Radar too. +1 For the Swift Team at Apple, we're looking into what workflows will work best for tracking issues and managing our engineering work in the two bug databases. We'd like to keep issues in JIRA as much as possible, but we'll also being using Radar heavily as we use it for managing our engineering work and tracking the resolution of issues/fixes into Apple's shipping tools. Cross-referencing between the two will be invaluable, and we'll likely invest some effort on our side to having some tooling to help bridge at least from JIRA issues to Radar so we can keep more of the core issue tracking in JIRA.___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
