Move Signal and SignalProducer operators to the concrete types. #304
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
andersio
force-pushed
the
3.1-concrete-same-type-req-2
branch
from
bbde8db to
5c07ffa
Compare
mdiep
approved these changes
Mar 31, 2017
andersio
force-pushed
the
3.1-concrete-same-type-req-2
branch
from
643e2f0 to
5c07ffa
Compare
andersio
force-pushed
the
3.1-concrete-same-type-req-2
branch
from
5c07ffa to
6d5331a
Compare
NachoSoto
approved these changes
Mar 31, 2017
| } | ||
| } | ||
|
|
||
| // FIXME: SWIFT_COMPILER_ISSUE |
There was a problem hiding this comment.
There was a problem hiding this comment.
For the ambiguity of then, my wild guess is that in concrete extensions, the compiler picks overloads among signatures with generic parameters resolved but no information about their original form. So the more specific overloads are ranked the same as the most generic overload.
This was referenced Apr 23, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SignalProducerheavily intertwines withSignalat its core, while bothSignalProducerandSignalare already pretty generic with refinements & specialisation enabled through closures & type erasure, IMO mitigating the need of another hot signal type. Moreover,Propertyis not going to conform to either of them due to clashes in base names, even assuming the presence of higher-kinded types in Swift.So with all these, I do not envision any value of semantic abstraction from these protocols.
The PR does not remove
SignalProtocolandSignalProducerProtocolhowever, since they are still necessary for constraining flattening operators until we have parameterised extensions.