Sent from my iPad
> On Jun 1, 2016, at 4:18 PM, Austin Zheng via swift-evolution > <swift-evolution@swift.org> wrote: > > After thinking about this topic for the past few days, I'd like to throw in > my support for "Any<>" as well. It's one magic construct to learn, looks like > a type, has the visual delineation, and shares continuity with both > protocol<> and Any today. > > I'd also like to express my support for the proposal to delineate generic and > existential syntax: all existentials must be written with Any<...>; generic > type constraints cannot use it. I hope this will make it clear to people > learning and using the language that, despite their superficial similarities, > they are actually two different concepts. I'm neutral on the syntax. But I strongly believe removing the ability to use protocol / Any in generic constraints *must* be accompanied by the introduction of a new (hopefully more robust) mechanism for factoring out common generic constraints. > > Austin > > >> On Wed, Jun 1, 2016 at 1:59 PM, Brent Royal-Gordon via swift-evolution >> <swift-evolution@swift.org> wrote: >> > [Proposal: >> > https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md >> > ] >> > >> > I’m late again to this one, but the discussion’s certainly still going. >> > I’m pretty strongly against the bare ‘A & B’ syntax, for a few reasons: >> > >> > - Swift doesn’t use ‘&’ for anything except bitwise AND. In particular, it >> > didn’t get picked for set intersection. >> >> I very, *very* much agree with this point. Thus far, Swift has been very >> conservative about overloading. It seems bizarre that we would violate that >> policy for these type combinators when much closer matches have been passed >> over. >> >> I also think that using `&` absolutely *begs* to have an `|` as well, and as >> much as the Ceylon people clamor for them, I don't think union types make >> sense in Swift. Unlike Ceylon, Swift uses an algebraic data type for >> Optional, doesn't use type-erased generics, and supports overloading. As far >> as I can tell, *none* of the reasons cited in the Ceylon language design FAQ >> <http://ceylon-lang.org/documentation/1.2/faq/language-design/> apply to >> Swift. >> >> (P.S. That language design FAQ is a *fantastic* document.) >> >> > - In theory people are allowed to overload ‘&’ to operate on types. That >> > doesn’t make sense for all types, but you could probably come up with a >> > particular type hierarchy or use of generics where it does make sense. >> > >> > - I don’t like types with spaces in them when the spaces aren’t bracketed >> > in some way. This is entirely an aesthetic objection, of the form “I don’t >> > naturally read that as a type, or even as a single unit, when looking at >> > code.” This isn’t a great objection because someone could have said it >> > about `[Int]` or `Int?` as well. (It would be a more realistic objection >> > if some of our brackets weren’t “<" and “>”.) >> >> To augment this: I think that if we're going to see a lot of little `where` >> clauses attached to types, you kind of have to have a bracketing syntax to >> put them in. And no, `(Collection where .Element == String)` doesn't count. >> `()` is about precedence, and this isn't a question of precedence; it's a >> question of making the type read as a single unit. >> >> > And I still support the ‘Any’ syntax, despite the “order doesn’t matter” >> > problem: >> > >> > - It’s consistent with the existing unconstrained ‘Any’ and with the >> > current dedicated wrapper types. If we didn’t think it was a good name for >> > those, we wouldn’t use it there either. >> >> One of my concerns with the `&` syntax is that it leaves no good way to >> define `Any`. I don't like having a magic `&` operator *and* a magic `Any` >> keyword, neither of which derives from anything more general. >> >> > - It’s easily learnable. It’s rare enough that someone wouldn’t be exposed >> > to it right away, like Optional, Array, and Dictionary sugar, but when >> > they do see it it’ll be obvious that it’s a type, and probably obvious >> > that it’s special because of the “Any”. >> > >> > - It’s a type; types always start with uppercase letters. (This has been >> > said plenty by others.) >> > >> > None of these are particularly strong arguments, I know, and I don’t have >> > a good alternate suggestion. But I did want to go on record as being in >> > favor of ‘Any’ and against a binary operator, even though that seems to >> > put me in the minority. >> >> I suspect that at least part of this is simply greater enthusiasm. I know I >> checked out of this thread for a few days while the `&` guys ran rampant. >> >> (P.S. A thought I had just now: If `Any` is our top type, then `All` would >> be a good name for our bottom type. And `All<Foo, Bar>` would be a good "All >> common supertypes of these types" operation. Both of these came up in the >> variadic generics thread, where we were talking about how to create a type >> representing any member of a tuple you were trying to splat in.) >> >> -- >> Brent Royal-Gordon >> Architechies >> >> _______________________________________________ >> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
