Thank you for pointing me to the right reading.
I just read both pages:
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md
https://github.com/apple/swift/blob/master/docs/Generics.rst
I’ll have to rewrite my proposal a bit. Btw. is there any better name for
Ceylon `Any<>`? Maybe `Either<>`?
`Any<T, U>` - "Any type that conforms to T and U“
Could someone explain to me what existentials suppose to be? I didn’t get that
part from the article, where everything else made somehow sense to me. :)
--
Adrian Zubarev
Sent with Airmail
Am 14. Mai 2016 bei 20:21:04, Austin Zheng via swift-evolution
(swift-evolution@swift.org) schrieb:
Yes, this is theoretically possible, but why is it useful? (I am genuinely
curious.)
If the intention is to allow B to be a user-defined extension point for T, this
goes back to the core team's arguments (in the thread about optional protocol
requirements) about why having checking for conformance to some requirement at
the use site is a suboptimal idea.
If the intention is to make the type system as expressive as possible, the core
team has already ruled out a number of features (user-defined variance on
generics, generic protocols) because they don't believe in their general
applicability.
Austin
On Sat, May 14, 2016 at 11:13 AM, Vladimir.S <sva...@gmail.com> wrote:
FWIW, yes, protocols available for struct are known at compile-time, but could
be unknown at the *moment of writing* the code.
What I mean:
Step 1. I write source code:
protocol A {}
protocol B {}
struct S:A {}
func f(a: A) {
if a is struct<S,B> {...} // I expect that S could be conformed to B
}
Step 2. I give my code to someone, who can do somewhere in his project:
extension S:B{..}
On 14.05.2016 7:06, Austin Zheng via swift-evolution wrote:
1. struct<SomeConcreteStruct, Protocol1, Protocol2>. In this case the
struct<...> representation is unnecessary; the protocols that are available
to the user are known at compile-time, and structs can't have subtypes that
conform to additional protocols like classes can. There is an example
marked "func boo(value: struct<SomeStruct>) /* equivalent to */ func
boo(value: SomeStruct)"; my question is why having more than two ways to
express the same idea makes the language better, easier to use, etc.
_______________________________________________
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
