Descriptive Protocol non-conformance errors


(Sean Alling) #1

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.

- Sean


(Douglas Gregor) #2

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.


(Xi Ge) #3

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 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:

  - Doug

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


(Ted Kremenek) #4

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.

   - 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:

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


(Michael Gottesman) #5

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.

  - Doug

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

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


(Sean Alling) #6

Sorry for the late reply,

Ted:

A JIRA? I know that’s issue tracking, where can I get one of those?

This is my first foray into the swift open source mailing lists, so I apologize for my certain level of novice.

···

_________________
Sean Alling
Mechanical Engineer
703 . 843 . 4808
allings@icloud.com <mailto:allings@vcu.edu>

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.

  - Doug

Do we have a JIRA issue for this idea?

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


(Dmitri Gribenko) #7

It is located here: https://bugs.swift.org/ .

Dmitri

···

On Sun, Jul 17, 2016 at 7:41 AM, Sean Alling via swift-dev <swift-dev@swift.org> wrote:

Sorry for the late reply,

Ted:

A JIRA? I know that’s issue tracking, where can I get one of those?

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Sean Alling) #8

Hey all,

I created a JIRA for this compiler feature request: SR-2233 (https://bugs.swift.org/browse/SR-2233).

Sean

···

_________________
Sean Alling
Mechanical Engineer
allings@icloud.com <mailto:allings@vcu.edu>

On 17 Jul , 2016, at 13:46, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Sun, Jul 17, 2016 at 7:41 AM, Sean Alling via swift-dev > <swift-dev@swift.org> wrote:

Sorry for the late reply,

Ted:

A JIRA? I know that’s issue tracking, where can I get one of those?

It is located here: https://bugs.swift.org/ .

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/