I found myself writting some method that parsed an API response and
wanted to use Decodable to map the response into a struct declared
elsewhere.
My idea was that each api response handler file (I use completely
different APIs that map into the same model) could add it's own
fileprivate conformance to decodable into the model struct so each api
response handler would use a different decoding function. But I found
the compiler telling me that is not possible.
I can easily change my design, is not an issue but I'm super curious.
Why fileprivate extensions can't add protocol conformance? Is there a
technical reason behind? or a conscience design?
Would love for this to be possible. It becomes an issue in mixed code: if
you include conformance to a <foo>Kit protocol in one of your Swift
classes, then you have to include the corresponding headers in every
Objective C file that includes the bridging .h file. The <foo>Kit classes
are added to the bridging header, but not the protocols. There are
workarounds (such as using an instance of a conforming nested class as a
proxy- nested classes are not emitted in the bridging header), but it's so
much cleaner to be able conform to the protocol privately. (Either that, or
fix the utility that builds the bridging header so it exposes the protocol
as well.)
Paul Schmidt | Smartsheet
Senior iOS Software Development Engineer
E: paul.schmidt@Smartsheet.com
C: 425.283.9576
On Mon, Feb 13, 2017 at 8:28 AM, Alejandro Martinez via swift-users < swift-users@swift.org> wrote:
Hi,
I found myself writting some method that parsed an API response and
wanted to use Decodable to map the response into a struct declared
elsewhere.
My idea was that each api response handler file (I use completely
different APIs that map into the same model) could add it's own
fileprivate conformance to decodable into the model struct so each api
response handler would use a different decoding function. But I found
the compiler telling me that is not possible.
I can easily change my design, is not an issue but I'm super curious.
Why fileprivate extensions can't add protocol conformance? Is there a
technical reason behind? or a conscience design?
I found myself writting some method that parsed an API response and
wanted to use Decodable to map the response into a struct declared
elsewhere.
My idea was that each api response handler file (I use completely
different APIs that map into the same model) could add it's own
fileprivate conformance to decodable into the model struct so each api
response handler would use a different decoding function. But I found
the compiler telling me that is not possible.
I can easily change my design, is not an issue but I'm super curious.
Why fileprivate extensions can't add protocol conformance? Is there a
technical reason behind? or a conscience design?
Extensions that add a protocol conformance are not allowed to have an access modifier applied because the conformance is currently required to have the same visibility as the protocol itself.
···
On Feb 13, 2017, at 10:28 AM, Alejandro Martinez via swift-users <swift-users@swift.org> wrote:
"is currently required to have the same visibility as the protocol itself"
that makes sense. I guess my question is more, is there a technical
reason for it?
···
On Mon, Feb 13, 2017 at 4:35 PM, Paul Schmidt <paul.schmidt@smartsheet.com> wrote:
Would love for this to be possible. It becomes an issue in mixed code: if
you include conformance to a <foo>Kit protocol in one of your Swift classes,
then you have to include the corresponding headers in every Objective C file
that includes the bridging .h file. The <foo>Kit classes are added to the
bridging header, but not the protocols. There are workarounds (such as using
an instance of a conforming nested class as a proxy- nested classes are not
emitted in the bridging header), but it's so much cleaner to be able conform
to the protocol privately. (Either that, or fix the utility that builds the
bridging header so it exposes the protocol as well.)
Paul Schmidt | Smartsheet
Senior iOS Software Development Engineer
E: paul.schmidt@Smartsheet.com
C: 425.283.9576
Work Better™
Learn More → smartsheet.com
On Mon, Feb 13, 2017 at 8:28 AM, Alejandro Martinez via swift-users > <swift-users@swift.org> wrote:
Hi,
I found myself writting some method that parsed an API response and
wanted to use Decodable to map the response into a struct declared
elsewhere.
My idea was that each api response handler file (I use completely
different APIs that map into the same model) could add it's own
fileprivate conformance to decodable into the model struct so each api
response handler would use a different decoding function. But I found
the compiler telling me that is not possible.
I can easily change my design, is not an issue but I'm super curious.
Why fileprivate extensions can't add protocol conformance? Is there a
technical reason behind? or a conscience design?
"is currently required to have the same visibility as the protocol itself"
that makes sense. I guess my question is more, is there a technical
reason for it?
The runtime and compiler do not support ‘non public’ conformances yet. We’ve started some of the plumbing required for this in the compiler because it is needed for other reasons (see my on-going SubstitutionMap work). However there are some interesting issues to resolve if we want to add this as a feature, in particular, around the behavior of dynamic casts.
Slava
···
On Feb 13, 2017, at 11:57 PM, Alejandro Martinez via swift-users <swift-users@swift.org> wrote:
On Mon, Feb 13, 2017 at 4:35 PM, Paul Schmidt > <paul.schmidt@smartsheet.com> wrote:
Would love for this to be possible. It becomes an issue in mixed code: if
you include conformance to a <foo>Kit protocol in one of your Swift classes,
then you have to include the corresponding headers in every Objective C file
that includes the bridging .h file. The <foo>Kit classes are added to the
bridging header, but not the protocols. There are workarounds (such as using
an instance of a conforming nested class as a proxy- nested classes are not
emitted in the bridging header), but it's so much cleaner to be able conform
to the protocol privately. (Either that, or fix the utility that builds the
bridging header so it exposes the protocol as well.)
Paul Schmidt | Smartsheet
Senior iOS Software Development Engineer
E: paul.schmidt@Smartsheet.com
C: 425.283.9576
Work Better™
Learn More → smartsheet.com
On Mon, Feb 13, 2017 at 8:28 AM, Alejandro Martinez via swift-users >> <swift-users@swift.org> wrote:
Hi,
I found myself writting some method that parsed an API response and
wanted to use Decodable to map the response into a struct declared
elsewhere.
My idea was that each api response handler file (I use completely
different APIs that map into the same model) could add it's own
fileprivate conformance to decodable into the model struct so each api
response handler would use a different decoding function. But I found
the compiler telling me that is not possible.
I can easily change my design, is not an issue but I'm super curious.
Why fileprivate extensions can't add protocol conformance? Is there a
technical reason behind? or a conscience design?