I’m suggesting a change to the compiler that returns an error when an object 'does not conform to protocol’ to nest sub-errors that’ll list what properties and methods the object hasn’t implemented.
I’m using the idea of a nested error so that the exceptions thrown will be grouped when shown. That was each doesn’t create a new error, racking up the error count, but rather just showing the developer the things he/she needs to implement.
I would *love* for us to have errors with Fix-Its that put in stub declarations for what you need to implement to conform to the protocol. I don’t think you should use sub-errors, though, because the structure doesn’t always come across well in IDEs. Rather, I’d suggest emitting one error per missing requirement, with a Fix-It that adds the proper declaration into the type/extension that declared conformance, and a note pointing to the requirement itself.
- Doug
···
On Jun 25, 2016, at 1:19 PM, Sean Alling via swift-dev <swift-dev@swift.org> wrote:
Hi everyone,
I’m suggesting a change to the compiler that returns an error when an object 'does not conform to protocol’ to nest sub-errors that’ll list what properties and methods the object hasn’t implemented.
I’m using the idea of a nested error so that the exceptions thrown will be grouped when shown. That was each doesn’t create a new error, racking up the error count, but rather just showing the developer the things he/she needs to implement.
I’m suggesting a change to the compiler that returns an error when an object 'does not conform to protocol’ to nest sub-errors that’ll list what properties and methods the object hasn’t implemented.
I’m using the idea of a nested error so that the exceptions thrown will be grouped when shown. That was each doesn’t create a new error, racking up the error count, but rather just showing the developer the things he/she needs to implement.
I would *love* for us to have errors with Fix-Its that put in stub declarations for what you need to implement to conform to the protocol. I don’t think you should use sub-errors, though, because the structure doesn’t always come across well in IDEs. Rather, I’d suggest emitting one error per missing requirement, with a Fix-It that adds the proper declaration into the type/extension that declared conformance, and a note pointing to the requirement itself.
+1. I believe fix-its are ultimate productivity tool for developers, one great example is to add protocol conformance stubs.
Similarly, we can use fixits to add empty declaration stubs when undefined variables are referred by users.
···
On Jul 6, 2016, at 8:24 PM, Douglas Gregor via swift-dev <swift-dev@swift.org> wrote:
On Jun 25, 2016, at 1:19 PM, Sean Alling via swift-dev <swift-dev@swift.org> wrote:
I’m suggesting a change to the compiler that returns an error when an object 'does not conform to protocol’ to nest sub-errors that’ll list what properties and methods the object hasn’t implemented.
I’m using the idea of a nested error so that the exceptions thrown will be grouped when shown. That was each doesn’t create a new error, racking up the error count, but rather just showing the developer the things he/she needs to implement.
I would *love* for us to have errors with Fix-Its that put in stub declarations for what you need to implement to conform to the protocol. I don’t think you should use sub-errors, though, because the structure doesn’t always come across well in IDEs. Rather, I’d suggest emitting one error per missing requirement, with a Fix-It that adds the proper declaration into the type/extension that declared conformance, and a note pointing to the requirement itself.
- Doug
Do we have a JIRA issue for this idea?
···
On Jul 6, 2016, at 8:24 PM, Douglas Gregor via swift-dev <swift-dev@swift.org> wrote:
On Jun 25, 2016, at 1:19 PM, Sean Alling via swift-dev <swift-dev@swift.org> wrote:
I have wanted this for a long time. (In fact I believe I filed a radar some time ago for this!)
Filling in the interface stubs saves so much time!
Michael
···
On Jul 6, 2016, at 8:40 PM, Xi Ge via swift-dev <swift-dev@swift.org> wrote:
On Jul 6, 2016, at 8:24 PM, Douglas Gregor via swift-dev <swift-dev@swift.org> wrote:
On Jun 25, 2016, at 1:19 PM, Sean Alling via swift-dev <swift-dev@swift.org> wrote:
Hi everyone,
I’m suggesting a change to the compiler that returns an error when an object 'does not conform to protocol’ to nest sub-errors that’ll list what properties and methods the object hasn’t implemented.
I’m using the idea of a nested error so that the exceptions thrown will be grouped when shown. That was each doesn’t create a new error, racking up the error count, but rather just showing the developer the things he/she needs to implement.
I would *love* for us to have errors with Fix-Its that put in stub declarations for what you need to implement to conform to the protocol. I don’t think you should use sub-errors, though, because the structure doesn’t always come across well in IDEs. Rather, I’d suggest emitting one error per missing requirement, with a Fix-It that adds the proper declaration into the type/extension that declared conformance, and a note pointing to the requirement itself.
+1. I believe fix-its are ultimate productivity tool for developers, one great example is to add protocol conformance stubs.
Similarly, we can use fixits to add empty declaration stubs when undefined variables are referred by users.
On 9 Jul , 2016, at 00:58, Ted kremenek <kremenek@apple.com> wrote:
On Jul 6, 2016, at 8:24 PM, Douglas Gregor via swift-dev <swift-dev@swift.org> wrote:
On Jun 25, 2016, at 1:19 PM, Sean Alling via swift-dev <swift-dev@swift.org> wrote:
Hi everyone,
I’m suggesting a change to the compiler that returns an error when an object 'does not conform to protocol’ to nest sub-errors that’ll list what properties and methods the object hasn’t implemented.
I’m using the idea of a nested error so that the exceptions thrown will be grouped when shown. That was each doesn’t create a new error, racking up the error count, but rather just showing the developer the things he/she needs to implement.
I would *love* for us to have errors with Fix-Its that put in stub declarations for what you need to implement to conform to the protocol. I don’t think you should use sub-errors, though, because the structure doesn’t always come across well in IDEs. Rather, I’d suggest emitting one error per missing requirement, with a Fix-It that adds the proper declaration into the type/extension that declared conformance, and a note pointing to the requirement itself.