IMO it will be nice to have ability to write:
func f(obj: A&B&C) {..}
if obj is A&B&C {...}
obj2 = obj as! A&B&C
(but I still don't understand real use case of things like (String | Int))
Btw, as we have `protocol` keyword for this feature to couple protocols,
why we can't have `class` keyword to merge class&protocols?
Like
func f(obj: class<SomeClass,SomeProtocl>) {..}
if obj is class<SomeClass,SomeProtocl> {..}
obj2 = obj as! class<SomeClass,SomeProtocol>
and yes, probably struct<SomeStruct,SomeProtocol>
On 13.05.2016 17:21, Tony Allevato via swift-evolution wrote:
I think there would be a certain elegance to allowing Boolean type
expressions wherever types are currently allowed, so `A & B` being a
replacement for `protocol<A, B>` might look nice, and then extend that to
allow concrete types as well. Then, if Swift ever decided to support union
types, the `|` operator naturally fits there.
One concern though would be whether parsing would get more complicated with
deeply composed expressions. If we only supported `&`, there's no real
nesting going on. But if we wanted to be forward thinking and leave the
door open for `|`, we might need to support things like `(String | Int) &
SomeProtocol`, and I'm not enough of a parser expert to know whether that
would really complicate things (e.g., could the compiler decide easily
enough that those parentheses are part of a type expression and not a
function type?).
`all<A, B>` would be a nice compromise in that case, and leave the door
open for `any<A, B>` in the future. So I'd be supportive of either option.
On Thu, May 12, 2016 at 1:30 PM Jordan Rose via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
We've been over this a few times before on the list. I personally like
naming this thing "Any<…>" in the same vein as "AnyObject", "AnyClass",
and "AnySequence". I also see Thorsten (and in the past Brent's?)
argument for calling it "all" or "All", because it's enforcing multiple
constraints.
I will say that "type" is unlikely to see much traction simply because
it is an /incredibly/ common name for both properties and locals. We
went through that exercise when trying to name both "static" and
"dynamicType" and decided that it would be too confusing, even if we
could make the parsing work.
The feature itself has definitely been shown to be useful when working
with the Cocoa frameworks, if not in general. I don't see it on JIRA
yet but we have it internally tracked in Radar as rdar://problem/15873071.
Jordan
On May 12, 2016, at 13:08, Adrian Zubarev via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I don’t get the part how `all<>` should allow `any<>`. Could you
explain that a little bit in detail (I’m not familiar with Ceylon)?
From my point of view `any<>` is something different that I pitched
here. `any<>` could be proposed in its own thread, because it is way
different than `type<>`. Or can we refine the rules of `type<>` to
get to `any<>`?
Here is a little example where `any<>` gets strange:
func foo(value: any<String, Int>) -> any<String, Int> {
// how would one use value here?
// what about its properties
// what will foo return and how to use the result
}
One benefit of `any<>` is the replacement of overloading, at least
for the type part of the function.
I’d like to propose `type<>` as the base extension to the language in
that direction, before we’ll move forward with more complex scenarios
(just like Chris did with generic typealias).
This function is clear that it only will work if you provide a
subclass of an UIView which conforms to SomeProtocol (nice addition
for library design).
func foo(value: type<UIView, SomeProtocol>) ->
type<UIView, SomeProtocol> {
// use it as a UIView and SomeProtocol at the same type
return value // return type works great
}
We can split the value just fine:
let mergedValue = foo(SomeViewThatWorks)
let view: UIView = mergedValue
let protocolValue: SomeProtocol = mergedValue
And merge it back together:
guard let newMergedValue = view as? type<UIView, SomeProtocol> else {
/* do something */ }
`all<>` could be seen as an alternative name for `type<>`, but to me
its not clear what `all<>` can do, whereas `type<>` is almost like
`protocol<>`.
--
Adrian Zubarev
Sent with Airmail
Am 12. Mai 2016 bei 21:40:24, Thorsten Seitz (tseit...@icloud.com
<mailto:tseit...@icloud.com>) schrieb:
Ceylon uses „&" for intersection types, i.e.
SomeRealClass & SomeProtocol
and the bar („|“) for union types, i.e.
String | Int
That has proven to be very lightweight and readable in Ceylon where
it is heavily used to good effect.
I agree with you that
type<SomeRealClass, SomeProtocol>
is much nicer than protocol<> for intersection types but to keep the
door open for union types, I would prefer
all<SomeRealClass, SomeProtocol>
This would allow
any<String, Int>
to be used for union types.
-Thorsten
Am 12.05.2016 um 16:09 schrieb Adrian Zubarev via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
protocol<SomeRealClass, SomeProtocol>
protocol<SomeRealStruct, SomeProtocol>
This feels really odd to me.
`type<SomeRealClass, SomeProtocol>` is more clear I’d say.
I think this would be a good addition to the type system and allow
us to build more complex and type save code.
But still I’d love to discuss if there might be
any disadvantages to this feature.
--
Adrian Zubarev
Sent with Airmail
Am 12. Mai 2016 bei 15:11:00, Vladimir.S (sva...@gmail.com
<mailto:sva...@gmail.com>) schrieb:
protocol<>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
