> Am 12.06.2016 um 17:40 schrieb L Mihalkovic <laurent.mihalko...@gmail.com>:
>
>>
>> On Jun 12, 2016, at 4:05 PM, Thorsten Seitz <tseit...@icloud.com
>> <mailto:tseit...@icloud.com>> wrote:
>>
>>>
>>> Am 12.06.2016 um 09:21 schrieb L. Mihalkovic <laurent.mihalko...@gmail.com
>>> <mailto:laurent.mihalko...@gmail.com>>:
>>>
>>>
>>>
>>>
>>> Regards
>>> (From mobile)
>>> On Jun 11, 2016, at 11:43 PM, Thorsten Seitz <tseit...@icloud.com
>>> <mailto:tseit...@icloud.com>> wrote:
>>>
>>>>
>>>>
>>>>> Am 11.06.2016 um 15:08 schrieb L. Mihalkovic
>>>>> <laurent.mihalko...@gmail.com <mailto:laurent.mihalko...@gmail.com>>:
>>>>>
>>>>>
>>>>>> On Jun 11, 2016, at 2:05 PM, Thorsten Seitz <tseit...@icloud.com
>>>>>> <mailto:tseit...@icloud.com>> wrote:
>>>>>>
>>>>>>
>>>>>>> Am 11.06.2016 um 12:38 schrieb L. Mihalkovic
>>>>>>> <laurent.mihalko...@gmail.com <mailto:laurent.mihalko...@gmail.com>>:
>>>>>>>
>>>>>>>
>>>>>>>> On Jun 11, 2016, at 11:30 AM, Thorsten Seitz <tseit...@icloud.com
>>>>>>>> <mailto:tseit...@icloud.com>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Am 11.06.2016 um 08:00 schrieb L. Mihalkovic
>>>>>>>>> <laurent.mihalko...@gmail.com <mailto:laurent.mihalko...@gmail.com>>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> (From mobile)
>>>>>>>>>> On Jun 10, 2016, at 9:35 PM, Thorsten Seitz via swift-evolution
>>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution
>>>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution
>>>>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> on Wed Jun 08 2016, Jordan Rose <swift-evolution@swift.org
>>>>>>>>>>>> <mailto:swift-evolution@swift.org>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution
>>>>>>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> on Wed Jun 08 2016, Thorsten Seitz
>>>>>>>>>>>>>
>>>>>>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>>>>>>>>>>> <mailto:swift-evolution@swift.org
>>>>>>>>>>>>>> <mailto:swift-evolution@swift.org>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ah, thanks, I forgot! I still consider this a bug, though
>>>>>>>>>>>>>>> (will have
>>>>>>>>>>>>>>> to read up again what the reasons are for that behavior).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, but in the case of the issue we're discussing, the choices
>>>>>>>>>>>>>> are:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Omit from the existential's API any protocol requirements
>>>>>>>>>>>>>> that depend
>>>>>>>>>>>>>> on Self or associated types, in which case it *can't* conform to
>>>>>>>>>>>>>> itself because it doesn't fulfill the requirements.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. Erase type relationships and trap at runtime when they don't
>>>>>>>>>>>>>> line up.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Matthew has been arguing against #2, but you can't “fix the bug”
>>>>>>>>>>>>>> without
>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> #1 has been my preference for a while as well, at least as a
>>>>>>>>>>>>> starting
>>>>>>>>>>>>> point.
>>>>>>>>>>>>
>>>>>>>>>>>> I should point out that with the resyntaxing of existentials to
>>>>>>>>>>>> Any<Protocols...>, the idea that Collection's existential doesn't
>>>>>>>>>>>> conform to Collection becomes far less absurd than it was, so
>>>>>>>>>>>> maybe this
>>>>>>>>>>>> is not so bad.
>>>>>>>>>>>
>>>>>>>>>>> I think the problem is more that Any<Collection> does not conform
>>>>>>>>>>> to a specific value for a type parameter T: Collection
>>>>>>>>>>>
>>>>>>>>>>> What I mean by this is that `Collection` denotes a type family, a
>>>>>>>>>>> generic parameter `T: Collection` denotes a specific (though
>>>>>>>>>>> unknown) member of that type family and `Any<Collection>` denotes
>>>>>>>>>>> the type family again, so there is really no point in writing
>>>>>>>>>>> Any<Collection> IMO.
>>>>>>>>>>> The type family cannot conform to T because T is just one fixed
>>>>>>>>>>> member of it.
>>>>>>>>>>> It conforms to itself, though, as I can write
>>>>>>>>>>> let c1: Any<Collection> = …
>>>>>>>>>>> let c2: Any<Collection> = c1
>>>>>>>>>>>
>>>>>>>>>>> That’s why I think that we could just drop Any<Collection> and
>>>>>>>>>>> simply write Collection.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Let me expand that a bit:
>>>>>>>>>>
>>>>>>>>>> Actually all this talk about existentials vs. generics or protocols
>>>>>>>>>> vs. classes has had me confused somewhat and I think there are still
>>>>>>>>>> some misconceptions present on this list sometimes, so I’ll try to
>>>>>>>>>> clear them up:
>>>>>>>>>>
>>>>>>>>>> (1) misconception: protocols with associated types are somehow very
>>>>>>>>>> different from generics
>>>>>>>>>>
>>>>>>>>>> I don’t think they are and I will explain why. The only difference
>>>>>>>>>> is the way the type parameters are bound: generics use explicit
>>>>>>>>>> parameter lists whereas protocols use inheritance. That has some
>>>>>>>>>> advantages (think long parameter lists of generics) and some
>>>>>>>>>> disadvantages.
>>>>>>>>>> These ways are dual in a notation sense: generic types have to have
>>>>>>>>>> all parameters bound whereas protocols cannot bind any of them.
>>>>>>>>>> The „existential“ notation `Any<>` being discussed on this list is
>>>>>>>>>> nothing more than adding the ability to protocols to bind the
>>>>>>>>>> parameters to be used just like Java’s wildcards are adding the
>>>>>>>>>> opposite feature to generics, namely not having to bind all
>>>>>>>>>> parameters.
>>>>>>>>>
>>>>>>>>> btw, i tried to to see if Any<> could have a simpler alternative
>>>>>>>>> https://gist.github.com/lmihalkovic/8aa66542f5cc4592e967bade260477ef
>>>>>>>>> <https://gist.github.com/lmihalkovic/8aa66542f5cc4592e967bade260477ef>
>>>>>>>>
>>>>>>>> As you know I like using `&` as type intersection operator. But you
>>>>>>>> write "The syntax leave a void when it comes to expressing the so
>>>>>>>> called Top type:“
>>>>>>>> Why? Just give the top type a name, e.g. `Any` and you are done.
>>>>>>> Yes.. I just don't like magic. I think that all types should be
>>>>>>> expressable with a syntax and that you can then decide to alias one
>>>>>>> parsing case with a specific name. Not the other way around.
>>>>>>
>>>>>> Well, I think that would be backwards, because we have a nominal type
>>>>>> system. That means that the syntax for a type is just its name.
>>>>>
>>>>> I realize we do not understand each other.
>>>>> The words we use now to describe a behavior are just that, words. As is
>>>>> the concepts they describe are useless to the computer running the
>>>>> compiler.
>>>>> So we need to map these concepts into a heuristic that a fast but dumb
>>>>> computer will be able to reason with. The code to do that will be either
>>>>> clean and organized, or it will look contrived and full of different
>>>>> paths that will be difficult to mesh together. Of all the possible ways
>>>>> in which swift can behave as a language, some will lead to the former,
>>>>> others to the latter code. I think this is not fate or something you find
>>>>> out after the decision was made and you struggle to carry it through.
>>>>> This is something that can partially be predicted. One of the tools for
>>>>> such prediction is to translate the concepts into a grammar that will
>>>>> show formalize the logic. The simpler the logic, the cleaner (not simple)
>>>>> the final code.
>>>>>
>>>>> Saying that the syntax for a type is a name is of no use whatsoever for
>>>>> the compiler implementer. It is so universally true that it cannot help
>>>>> in any way whatsoever decide the shape of the swift grammar, much less
>>>>> the structure of the c++ code implementing it.
>>>>>
>>>>>> `&` is a type operator which creates a new type from its operands.
>>>>>> `where` clauses add constraints to types.
>>>>>> But it all starts with a type's name.
>>>>>>
>>>>>> The only magic would be that all type definitions (`protocol` etc.)
>>>>>> which do not give a supertype they conform to, will implicitly conform
>>>>>> to `Any`, i.e.
>>>>>
>>>>> I call magic the core notions of swift that cannot be expressed in swift
>>>>> but have to parachutted in by the compiler. If you read Chris' initial
>>>>> message you will see that he said as much, that adopting P&Q as syntax
>>>>> was leaving a gap that the compiler would have to magically fill.
>>>>>
>>>>>
>>>>>>
>>>>>> protocol Foo { … }
>>>>>>
>>>>>> means
>>>>>>
>>>>>> protocol Foo : Any { … }
>>>>>>
>>>>>> That’s less magic than creating a special syntax just to express the top
>>>>>> type.
>>>>>
>>>>> I will try again... Would it be easier to understand it if instead of
>>>>> magic I said arbitrary? You are creating a special case: you decide
>>>>> arbitrarily that the special series of characters 'A' 'n' 'y' with this
>>>>> precise casing and without any spaces is going to be adorned with a
>>>>> special meaning when used in specific situations. This is not something
>>>>> you deduced. My approach is exactly the opposite: _[] does not describe
>>>>> the top type because I have a special affinity with these characters, it
>>>>> describes the top type because it is the only possible logical conclusion
>>>>> from having followed a set of rules attached to a syntax that describes
>>>>> ALL existentials. And because it is not particularly savory, I typealias
>>>>> it to something else. But this is not in the compiler, it us in the
>>>>> standard linrary... inside swift, not outside.
>>>>
>>>> Ok, that's a good argument. But your proposal does not contain those rules.
>>>> Why should _[] describe the top type? You just say this in your proposal,
>>>> but you do not define rules what _[] means.
>>>> _[A,B]
>>>
>>> don't know where this comes from. This is incorrect and the parser would
>>> reject it.
>>>
>>>> describes the type intersection of A and B, i.e. it contains all members
>>>> of A which are also members of B. _[] does not list any types, so one
>>>> might conclude that it has no members and therefore must be the bottom
>>>> type!
>>> Are you saying that protocol<> is the bottom type of Swift then? Because if
>>> you disect the logic it follows to explain why it is a top type and apply
>>> the exact same reasoning to _[] then you should reach the same conclusion
>>> {same effects produce the same conclusions}
>>>
>>>> Or _[A,B] in reality means _[A,B,Any],i.e. A & B & Any which of course is
>>>> equal to A & B. Then _[] would just mean Any, but we would have had to
>>>> introduce the top type explicitly again.
>>> From cause to effects. Any is an effect (a conclusion we reach) rather than
>>> a cause (something we posit before starting the discussion). Like I
>>> explained, Any is a stdlib provided convenient typealias for _[] as opposed
>>> to a parachuted concept born inside the compiler. Btw, it means a different
>>> stdlib could redefine it as All, without altering the compiler. Any is not
>>> core to swift's structure, but _[] is because it is borne out of the
>>> mechanical uniformity of the grammar.
>>>
>>>> On the other hand if we declare a protocol Any and define protocol A {...}
>>>> to mean protocol A: Any {...} there is not really something special in the
>>>> compiler except for adding the conformance which seems very minor to me.
>>>> Everything else is just standard behavior of the type system.
>>>
>>> You are back to adding some magic that I just demonstrated is not required
>>> if the grammar is simple (not that i could add it to my grammar to please
>>> you, but then it would not eliminate any of the other definitions, and
>>> would just complicate the parser and type checker to ensure that people use
>>> it correctly. Per Ockham's principle, the system i describe is a better
>>> alternative.
>>>
>>>>
>>>>
>>>>> Read Chris' original announcement.. He describes P&Q as it would be
>>>>> adopted today as being just a CORNER CASE of a single general
>>>>> principal... a single grammar that can work today to describe P&Q as well
>>>>> as generalize existentials tomorrow. No special treatment, single parser,
>>>>> single rule. I don't like to write un-necessary IF statements in code.
>>>>
>>>> Sorry, I do not understand what you mean here: where would you have to
>>>> write unnecessary if-statements?
>>>
>>> Close your eyes and make a mental representation of what the code to
>>> implement the Any<....> proposal will necessarily look like... that is what
>>> I am referring to. That code cannot not be uggly. Because some of of things
>>> a parser typically should catch are not discernsble, and therefore have to
>>> be differed to the type checker. By comparison, look at the grammar I wrote
>>> and picture the code to implement it. The picture will look very different,
>>> and the parser can already eliminate a lot of things that never reach the
>>> type checker.
>>>
>>>>
>>>>
>>>>>
>>>>>>>> Why should the top type have special *syntax*? It is just the type all
>>>>>>>> other types conform to. No need to do something special here and
>>>>>>>> therefore no need to invent an alternative syntax like `Any<>` or the
>>>>>>>> alternative from your gist which is rather confusing IMO (and I don’t
>>>>>>>> like the special case given to classes in the syntax).
>>>>>>> The _[] case is just a degenerate case of the syntax, showing that it
>>>>>>> is expressible inside, as opposoed to have to define a contextual
>>>>>>> keyword (read the SourceKit code). And then it is aliasable. Part of
>>>>>>> the problems in swift today to me is that some things are no doable in
>>>>>>> swift, so the compiler must contain that semantic. This here is just
>>>>>>> one example, but there are others. These are notions that the standard
>>>>>>> library has to defer to the compiler. Some of them have been tabled for
>>>>>>> 4.0 it seems. My point here was that it is not fate, and choosing the
>>>>>>> syntax carefully for existentials (whichever it is, i don't really care
>>>>>>> inthe end) would prevent having to add a magic keyword for to top type
>>>>>>> to the compiler and to SourceKit again (they are trying to remove them).
>>>>>>
>>>>>> `Any` would *not* be a keyword. It is just a type name like `Collection`
>>>>>> or `Int`. Like I said, the only magic would be in adding `: Any` to type
>>>>>> definitions without a conforming clause.
>>>>>
>>>>> I hope that by now you understand what magic I was talking about.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> As for the current Any<...> proposal for generalizing existentials it
>>>>>>> is IMHO cluncky and magic. There is nothing stopping us mechanically
>>>>>>> from entering Any<UITableView, UIButton>. To me that is the holemark of
>>>>>>> bad design. In what I tested you just can't do it and the reason is
>>>>>>> clear. Of course when I
>>>>>>
>>>>>> `Any<UITableView, UIButton>` is just an intersection type and would be
>>>>>> written UITableView & UIButton. And, yes, that would be ok, because it
>>>>>> would be just the empty set, i.e. the bottom type (which has no
>>>>>> members). There is no magic involved, it is just the normal result of an
>>>>>> intersection: each type is a set containing all instances of this type
>>>>>> (instances conforming to it)
>>>>>
>>>>> You can't be serious? You are saying that to you the ide should not be
>>>>> telling us we are writting an absurdity? And this one was obvious, but it
>>>>> gets a lot worse with more complex types.
>>>>
>>>
>>> Take a screenshot next time you see a "let x:Any<UITableView, UIButton>" in
>>> an app and send it to me. The absurdity would be for the compiler to
>>> generate a binary, the app to start, and us to wonder why x the code
>>> depending on x would never execute. Seems obvious to you why now?
>>
>> I’m taking an example from Gavin King’s presentation about Ceylon instead
>> which can be found here:
>> https://greenjug.java.net/resources/CeylonEastCoastTour20141016.pdf
>> <https://greenjug.java.net/resources/CeylonEastCoastTour20141016.pdf>
>
> my understanding is that dave is the type system designer. I will let the two
> of you finish this conversation and just read.
:-)
We’ll probably see after WWDC what he thinks…
Best regars
-Thorsten
>
> very best
>
>
>
>>
>> <PastedGraphic-1.tiff>
>>
>> Object is the abstract supertype of all types representing definite values,
>> i.e. which are not null. Remember that in Ceylon Optional<T> is modeled as
>> type union T | Null, where Null is the type containing the single member
>> null (i.e. nil in Swift).
>> Element is the type parameter for the elements of Iterable.
>>
>> Element might be String | Null, for example (in Ceylon abbreviated as
>> String? just like in Swift).
>> Element & Object can only be String, because Null & Object is empty, i.e. is
>> the bottom type:
>>
>> (String | Null) & Object = (String & Object) | (Null & Object) = String |
>> Bottom = String
>>
>> So, while you don’t see UITableView & UIButton here, there is Null & Object
>> at work which yields the bottom type, just like UITableView & UIButton
>> would.
>> If this was forbidden, then how would the type system be able to simplify
>> the expression (String | Null) & Object?
>>
>>>
>>> not debatting past here I can't see how it relates (it is interesting but
>>> you may want to look at the whole thing from a 'whats usefull' perspective,
>>> rather than as 'whats combinatorially possible‘
>>
>> Like the slide above hopefully demonstrated this is not just a nice
>> theoretical exercise but it *is* useful if you use the whole abstraction and
>> do not try to arbitrarily single out special cases as forbidden.
>>
>> Of course, writing UITableView & UIButton is not useful, but writing
>> something like T & Object is, but it needs the whole general mechanism to
>> work.
>> (And that general mechanism will show you automatically that UITableView &
>> UIButton is not useful, because you can’t call any method on it, *without*
>> having to introduce compiler magic or IDE magic to explicitly forbid this.)
>>
>> Hope that made sense now :-)
>>
>> -Thorsten
>>
>>
>>
>>>
>>>> Why is an empty intersection absurd? The beauty is that all type
>>>> expressions sort out automatically by applying simple set rules. And it
>>>> actually does make sense!
>>>>
>>>> struct Set<T> {
>>>> // answer any one element
>>>> func any() -> T?
>>>> }
>>>> func intersect<T, U>(a: Set<T>, b: Set<U>) -> Set<T & U> {...}
>>>>
>>>> let x: Set<UITableView> = ...
>>>> let y: Set<UIButton> = ..
>>>> let z = intersect(x, y) // has type Set<Bottom>
>>>> z.any // has type Optional<Bottom> and therefore can only be nil
>>>>
>>>> Therefore the type system statically knows that the intersection of those
>>>> sets is always empty. No need to declare this as invalid. It just works
>>>> correctly and gives the results you would expect without need for special
>>>> casing and compiler magic (which we both would like to keep small).
>>>>
>>>> -Thorsten
>>>>
>>>>
>>>>>> . Intersecting two sets might result in an empty set. The type denoting
>>>>>> the empty set is the bottom type which is the subtype of all types and
>>>>>> might be called `Nothing` or `Never` or `Bottom`.
>>>>>> Ceylon makes very nice use of type intersections and type unions and the
>>>>>> beautiful thing is that these type operations really just work like you
>>>>>> would expect if you think of types as sets (which is the standard
>>>>>> definition for a type AFAIK). No surprises and no magic there!
>>>>>>
>>>>>> So it is *not* a sign of bad design, quite to the contrary! What did you
>>>>>> test it with? Probably not Ceylon, because otherwise you would have seen
>>>>>> that it just works.
>>>>>
>>>>> Hey, who knows, ceylon may one day come to llvm...
>>>>>
>>>>>>
>>>>>>
>>>>>>> say you can't I do not mean that your keyboard will zap u if you try.
>>>>>>> But the way to verify correctness is different... and in a world where
>>>>>>> xcode would be a good ide, then code completion would even show you why
>>>>>>> and actually truly assist (because the grammar i tested makes really
>>>>>>> makes it possible). I know that xcode is only as good as SourceKit lets
>>>>>>> it be.
>>>>>>>
>>>>>>>>>
>>>>>>>>>> Essentially `Any<Collection>` in Swift is just the same as
>>>>>>>>>> `Collection<?>` in Java (assuming for comparability’s sake that
>>>>>>>>>> Swift’s Collection had no additional associated types; otherwise I
>>>>>>>>>> would just have to introduce a Collection<Element, Index> in Java).
>>>>>>>>>>
>>>>>>>>>> Likewise `Any<Collection where .Element: Number>` is just the same
>>>>>>>>>> as `Collection<? extends Number>` in Java.
>>>>>>>>> Java supports co/contra variant params
>>>>>>>>
>>>>>>>> Java has no declaration-site variance like Ceylon or Scala have (see
>>>>>>>> e.g.
>>>>>>>> http://ceylon-lang.org/blog/2014/07/14/wildcards#why_i_distrust_wildcards_and_why_we_need_them_anyway
>>>>>>>>
>>>>>>>> <http://ceylon-lang.org/blog/2014/07/14/wildcards#why_i_distrust_wildcards_and_why_we_need_them_anyway>).
>>>>>>>>
>>>>>>>> Java’s wildcards are a way to express use-site variance. The proposed
>>>>>>>> `Any<>` does just the same.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> And just like Collection<?> does not conform to a type parameter `T
>>>>>>>>>> extends Collection<?>` because Collection<?> is the type `forall E.
>>>>>>>>>> Collection<E>` whereas `T extends Collection<?>` is the type `T.
>>>>>>>>>> Collection<T>` for a given T.
>>>>>>>>>
>>>>>>>>> This picture is accurate today, but there are going to be more
>>>>>>>>> serious differences after 10 no date is currently geven for when it
>>>>>>>>> will come)
>>>>>>>>
>>>>>>>> You mean Java 10?
>>>>>>>
>>>>>>> Yes. After 10. Than is their only date hint.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> In essence protocols with associated types are like generics with
>>>>>>>>>> wildcards.
>>>>>>>>>
>>>>>>>>> Yes, java has kept everything within its generics system rather than
>>>>>>>>> split parts out. Something people may not immediately think about
>>>>>>>>> with respect to the 2 generic systems is that when u call a
>>>>>>>>> func<T>capture(T t){} in java with a wildcard you are doing a
>>>>>>>>> compile time capture only (to avoid the dreaded unsafe casts),
>>>>>>>>> whereas it is really nice to do the same in swift and subsequently be
>>>>>>>>> able to access T.Type and see that it is not Any. The closest u ever
>>>>>>>>> get to that type at runtime in java is via generics introspection,
>>>>>>>>> but u still can't do everything ( like no new T() ). But today the
>>>>>>>>> bridging between existential types and generics is definitely a work
>>>>>>>>> in progress.
>>>>>>>>>
>>>>>>>>>> Coming back to the questions whether (a) allowing existentials to be
>>>>>>>>>> used as types is useful and (b) whether sacrificing type safety
>>>>>>>>>> would somehow be necessary for that, I think we can safely answer
>>>>>>>>>> (a) yes, it *is* useful to be able to use existentials like
>>>>>>>>>> Any<Collection> as types, because wildcards are quite often needed
>>>>>>>>>> and very useful in Java (they haven’t been added without a reason)
>>>>>>>>>
>>>>>>>>> IMO they made java 8 (referring to streams). And even though the
>>>>>>>>> syntax for co/contra variance is pretty heavy, it is the foundation
>>>>>>>>> for all modern java code. The any-fication of the generics is going
>>>>>>>>> to open new doors as some of it will translate into a partial
>>>>>>>>> reification in the jvm. It seems the decision for now is to not use
>>>>>>>>> the extra info in java to retain binary compatibility with all the
>>>>>>>>> erased code out there, this is something scala might use in areas
>>>>>>>>> where it won't mind loosing java compatibility.
>>>>>>>>>
>>>>>>>>>> (b) no, sacrificing type safety does not make sense, as the
>>>>>>>>>> experience with Java’s wildcards shows that this is not needed.
>>>>>>>>>> Especially if something like path dependent types is used like
>>>>>>>>>> proposed and some notation to open an existential’s type is added,
>>>>>>>>>> which is both something that Java does not have.
>>>>>>>>>
>>>>>>>>> I hope typesafe opening inside the " if let " syntax gets added. I
>>>>>>>>> know that chris is against sugaring, but I played if an
>>>>>>>>> implementation of
>>>>>>>>>
>>>>>>>>> ... x is String?
>>>>>>>>> If let! x {}
>>>>>>>>> That runs as
>>>>>>>>> if let x = x {}
>>>>>>>>>
>>>>>>>>> something equally short could be done here.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> (2) misconception: POP is different from OOP
>>>>>>>>>>
>>>>>>>>>> It is not. Protocols are just interfaces using subtyping like OOP
>>>>>>>>>> has always done. They just use associated types instead of explicit
>>>>>>>>>> type parameters for generics (see above). The more important
>>>>>>>>>> distinction of Swift is emphasizing value types and making mutation
>>>>>>>>>> safely available by enforcing copy semantics for value types.
>>>>>>>>>
>>>>>>>>> Values are coming to the jvm, which will narrow this gap (like their
>>>>>>>>> view identity for value vs ref and the whole deep ==) . I also really
>>>>>>>>> like the cow approach of the swift runtime.
>>>>>>>>>
>>>>>>>>>> But protocols are not really different from interfaces in Java.
>>>>>>>>>
>>>>>>>>> There is one big difference: default methods, but it seems swift will
>>>>>>>>> add that soon.
>>>>>>>>
>>>>>>>> Swift already has default extension methods, doesn’t it?
>>>>>>>
>>>>>>> Yes, and no. It has differently dispatched code that can be found to
>>>>>>> fill in the gap of the conformance req, yes. But Joe Grof (?) said that
>>>>>>> there are no reasons why these could not be added. Having true defaults
>>>>>>> could be one way to deal with optional comformance…
>>>>>>
>>>>>> The dispatch issue only arises for extensions introducing a method that
>>>>>> is not declared in a protocol. That is something you *cannot* do in
>>>>>> Java. Java’s default methods are implementations for methods declared in
>>>>>> interfaces. Swift’s extension methods providing defaults for methods
>>>>>> declared in a protocol are dynamically dispatched and should work like
>>>>>> Java’s default methods.
>>>>>
>>>>> I think we should agree to disagree.
>>>>>
>>>>>
>>>>>> (One caveat exists with subclasses where the superclasses didn’t
>>>>>> implement the method because I then am not allowed to `override` the
>>>>>> default method but that is a bug IMO).
>>>>>>
>>>>>> -Thorsten
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> protocol MyProto {
>>>>>>> func mustImplement()
>>>>>>> default canImplement() { }
>>>>>>> }
>>>>>>>
>>>>>>> Related data there:
>>>>>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018560.html
>>>>>>>
>>>>>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018560.html>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I also really like how extensions and conformance mix together in
>>>>>>>>> swift to bake retro-modelling in and the adapter pattern (spent
>>>>>>>>> enough years deep diving inside eclipse to appreciate it).
>>>>>>>>>
>>>>>>>>>> I would have preferred a unified model using just classes with real
>>>>>>>>>> multiple inheritance like Eiffel has and value types just being a
>>>>>>>>>> part of that similar to Eiffel’s `expanded` classes. But that ship
>>>>>>>>>> has probably sailed a long time ago :-/
>>>>>>>>
>>>>>>>> I like extensions very much (having used Smalltalk for a long time). I
>>>>>>>> like enums for the pattern matching and structs as value types. But
>>>>>>>> having to split protocols off instead of using abstract classes makes
>>>>>>>> things more complicated IMO.
>>>>>>>>
>>>>>>>>> -1 i am old school c/c++... i really like protocol, struct, class,
>>>>>>>>> extensions, enums. It is a really nice mix that gives objc people
>>>>>>>>> room to grow, but I do miss how they are an integral part of generics
>>>>>>>>> (i protocols as a replacement and look forward to when they interact
>>>>>>>>> better) and namespaces+scoped-imports (c#)... Looking forward to
>>>>>>>>> where things go next
>>>>>>>>
>>>>>>>> Yeah, namespacing/submodules/conflict resolution (when doing imports
>>>>>>>> but also when conforming to multiple protocols which has just the same
>>>>>>>> problems) are still missing. But I’m optimistic :-) Let’s complete
>>>>>>>> generics first, then tackle existentials/type intersections.
>>>>>>>
>>>>>>> I think I care more about existentials, but only because of the kind of
>>>>>>> java i wrote for a living. I just looked at a bunch of opensource swift
>>>>>>> libs (particularly for server side swift)... some of it is a real
>>>>>>> engineering disaster: 20+ folders, each with 2 source files... or 3
>>>>>>> folders "extensions" "utils" "classes". Swift is currently not equiped
>>>>>>> for people to write big things with... I wish the team would address it
>>>>>>> sooner than later (look at their own c++ code to see the difference).
>>>>>>> IMHO import conflicts are more often the symptom of bad code than a
>>>>>>> real issue.
>>>>>>
>>>>>> Alas, most languages suffer from poor module systems. A good module
>>>>>> system should not only allow resolving conflicts between modules and
>>>>>> making it possible to structure code well, but solve the issue around
>>>>>> versioned modules so that is is possibly to safely use different
>>>>>> versions of the same module in the same application.
>>>>>>
>>>>>> -Thorsten
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Cheers
>>>>>>>>
>>>>>>>> -THorsten
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> So be it. But at least there should be no reasons for POP vs OOP
>>>>>>>>>> wars ;-)
>>>>>>>>>> (I’d like to add that I liked Dave’s talks at last WWDC very much,
>>>>>>>>>> it’s just that I don’t think that POP is something new or different.)
>>>>>>>>>
>>>>>>>>> I used to thin that way. But today I think that although in broad
>>>>>>>>> brush strokes the similarities and bigger than the differences, there
>>>>>>>>> is room for making a bigger difference in the how.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -Thorsten
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> swift-evolution mailing list
>>>>>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
