Xcode Fix-It action for returning closures

Hi Swift community,

I was wondering if we have considered adding support for providing Xcode automatic fix-it’s for closures being returned from a function.

For example, here is an incorrect version of a function that requires two `@escaping` keywords to be inserted.

func mapping <A, B, C> (f: (A) -> (B)) -> ((C, B) -> (C)) -> ((C, A) -> (C))

Despite the complexity, the compiler manages to catch two errors.

1. Closure use of non-escaping parameter `f` may allow it to escape
a. Automatic Fix-it by doing `f: @escaping (A) - > (B)`

2. Closure use of non-escaping parameter `reducer` may allow it to escape
b. No Fix-it provided <————

As you see above, the two places where a compile-time error occurred had the same exact problem; they both needed a `@escaping`. However, while the function parameter was offered an automatic fix-it, the nested closure being returned was not.

Here’s the correct version of the function.

func mapping <A, B, C> (f: @escaping (A) -> (B)) -> (@escaping ((C, B) -> (C))) -> ((C, A) -> (C)) {
return { reducer in
return { accum, input in
reducer(accum, f(input))
}
}
}

I know this is a small feature for a very specific use case but I think it could help make Xcode a little smarter :smiley:
Thanks for reading!

You should probably file a Radar for this, since Xcode isn’t part of the Swift project.

Saagar Jha

···

On Jul 13, 2017, at 19:46, iCloud via swift-evolution <swift-evolution@swift.org> wrote:

Hi Swift community,

I was wondering if we have considered adding support for providing Xcode automatic fix-it’s for closures being returned from a function.

For example, here is an incorrect version of a function that requires two `@escaping` keywords to be inserted.

func mapping <A, B, C> (f: (A) -> (B)) -> ((C, B) -> (C)) -> ((C, A) -> (C))

Despite the complexity, the compiler manages to catch two errors.

1. Closure use of non-escaping parameter `f` may allow it to escape
a. Automatic Fix-it by doing `f: @escaping (A) - > (B)`

2. Closure use of non-escaping parameter `reducer` may allow it to escape
b. No Fix-it provided <————

As you see above, the two places where a compile-time error occurred had the same exact problem; they both needed a `@escaping`. However, while the function parameter was offered an automatic fix-it, the nested closure being returned was not.

Here’s the correct version of the function.

func mapping <A, B, C> (f: @escaping (A) -> (B)) -> (@escaping ((C, B) -> (C))) -> ((C, A) -> (C)) {
    return { reducer in
        return { accum, input in
            reducer(accum, f(input))
        }
    }
}

I know this is a small feature for a very specific use case but I think it could help make Xcode a little smarter :smiley:
Thanks for reading!

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

AFAIK, fix-it is driven by the Swift compiler/source kit.

···

Le 13 juil. 2017 à 23:17, Saagar Jha via swift-evolution <swift-evolution@swift.org> a écrit :

You should probably file a Radar for this, since Xcode isn’t part of the Swift project.

Saagar Jha

On Jul 13, 2017, at 19:46, iCloud via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi Swift community,

I was wondering if we have considered adding support for providing Xcode automatic fix-it’s for closures being returned from a function.

For example, here is an incorrect version of a function that requires two `@escaping` keywords to be inserted.

func mapping <A, B, C> (f: (A) -> (B)) -> ((C, B) -> (C)) -> ((C, A) -> (C))

Despite the complexity, the compiler manages to catch two errors.

1. Closure use of non-escaping parameter `f` may allow it to escape
a. Automatic Fix-it by doing `f: @escaping (A) - > (B)`

2. Closure use of non-escaping parameter `reducer` may allow it to escape
b. No Fix-it provided <————

As you see above, the two places where a compile-time error occurred had the same exact problem; they both needed a `@escaping`. However, while the function parameter was offered an automatic fix-it, the nested closure being returned was not.

Here’s the correct version of the function.

func mapping <A, B, C> (f: @escaping (A) -> (B)) -> (@escaping ((C, B) -> (C))) -> ((C, A) -> (C)) {
    return { reducer in
        return { accum, input in
            reducer(accum, f(input))
        }
    }
}

I know this is a small feature for a very specific use case but I think it could help make Xcode a little smarter :smiley:
Thanks for reading!

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

This has been reported as SR-5556 <https://bugs.swift.org/browse/SR-5556>. In the future, please report bugs like this through bugs.swift.org <http://bugs.swift.org/> and/or Radar.

Thanks,

~Robert Widmann

···

On Jul 13, 2017, at 7:46 PM, iCloud via swift-evolution <swift-evolution@swift.org> wrote:

Hi Swift community,

I was wondering if we have considered adding support for providing Xcode automatic fix-it’s for closures being returned from a function.

For example, here is an incorrect version of a function that requires two `@escaping` keywords to be inserted.

func mapping <A, B, C> (f: (A) -> (B)) -> ((C, B) -> (C)) -> ((C, A) -> (C))

Despite the complexity, the compiler manages to catch two errors.

1. Closure use of non-escaping parameter `f` may allow it to escape
a. Automatic Fix-it by doing `f: @escaping (A) - > (B)`

2. Closure use of non-escaping parameter `reducer` may allow it to escape
b. No Fix-it provided <————

As you see above, the two places where a compile-time error occurred had the same exact problem; they both needed a `@escaping`. However, while the function parameter was offered an automatic fix-it, the nested closure being returned was not.

Here’s the correct version of the function.

func mapping <A, B, C> (f: @escaping (A) -> (B)) -> (@escaping ((C, B) -> (C))) -> ((C, A) -> (C)) {
    return { reducer in
        return { accum, input in
            reducer(accum, f(input))
        }
    }
}

I know this is a small feature for a very specific use case but I think it could help make Xcode a little smarter :smiley:
Thanks for reading!

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

A bug report has been filed under SR-5455.

Thanks for the suggestions!

···

On 2017년 7월 16일 AM 9:52 +0900, Félix Cloutier <felixcca@yahoo.ca>, wrote:

AFAIK, fix-it is driven by the Swift compiler/source kit.

> Le 13 juil. 2017 à 23:17, Saagar Jha via swift-evolution <swift-evolution@swift.org> a écrit :
>
> You should probably file a Radar for this, since Xcode isn’t part of the Swift project.
>
> Saagar Jha
>
> > On Jul 13, 2017, at 19:46, iCloud via swift-evolution <swift-evolution@swift.org> wrote:
> >
> > Hi Swift community,
> >
> > I was wondering if we have considered adding support for providing Xcode automatic fix-it’s for closures being returned from a function.
> >
> > For example, here is an incorrect version of a function that requires two `@escaping` keywords to be inserted.
> >
> > func mapping <A, B, C> (f: (A) -> (B)) -> ((C, B) -> (C)) -> ((C, A) -> (C))
> >
> > Despite the complexity, the compiler manages to catch two errors.
> >
> > 1. Closure use of non-escaping parameter `f` may allow it to escape
> > a. Automatic Fix-it by doing `f: @escaping (A) - > (B)`
> >
> > 2. Closure use of non-escaping parameter `reducer` may allow it to escape
> > b. No Fix-it provided <————
> >
> > As you see above, the two places where a compile-time error occurred had the same exact problem; they both needed a `@escaping`. However, while the function parameter was offered an automatic fix-it, the nested closure being returned was not.
> >
> > Here’s the correct version of the function.
> >
> > func mapping <A, B, C> (f: @escaping (A) -> (B)) -> (@escaping ((C, B) -> (C))) -> ((C, A) -> (C)) {
> > return { reducer in
> > return { accum, input in
> > reducer(accum, f(input))
> > }
> > }
> > }
> >
> > I know this is a small feature for a very specific use case but I think it could help make Xcode a little smarter :smiley:
> > Thanks for reading!
> >
> >
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Terms of Service

Privacy Policy

Cookie Policy