> On Jun 12, 2016, at 4:05 PM, Thorsten Seitz <[email protected]> wrote:
>
>
>> Am 12.06.2016 um 09:21 schrieb L. Mihalkovic <[email protected]>:
>>
>>
>>
>>
>> Regards
>> (From mobile)
>> On Jun 11, 2016, at 11:43 PM, Thorsten Seitz <[email protected]> wrote:
>>
>>>
>>>
>>>> Am 11.06.2016 um 15:08 schrieb L. Mihalkovic
>>>> <[email protected]>:
>>>>
>>>>
>>>>> On Jun 11, 2016, at 2:05 PM, Thorsten Seitz <[email protected]> wrote:
>>>>>
>>>>>
>>>>>> Am 11.06.2016 um 12:38 schrieb L. Mihalkovic
>>>>>> <[email protected]>:
>>>>>>
>>>>>>
>>>>>>> On Jun 11, 2016, at 11:30 AM, Thorsten Seitz <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Am 11.06.2016 um 08:00 schrieb L. Mihalkovic
>>>>>>>> <[email protected]>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> (From mobile)
>>>>>>>>> On Jun 10, 2016, at 9:35 PM, Thorsten Seitz via swift-evolution
>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution
>>>>>>>>>> <[email protected]>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution
>>>>>>>>>>> <[email protected]>:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> on Wed Jun 08 2016, Jordan Rose <[email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution
>>>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> on Wed Jun 08 2016, Thorsten Seitz
>>>>>>>>>>>>
>>>>>>>>>>>>> <[email protected]
>>>>>>>>>>>>> <mailto:[email protected]>>
>>>>>>>>>>>>> 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
>>>>>>>
>>>>>>> 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
>
>
>
> 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,
you had me wondering for a moment
As for ceylon, it has come a long way and is great, but i don't like it anymore
today than I did 4 years ago (all along i always preferred kotlin).
Professionally, my poisons of choice are c, c++, java, scala, c#, xtend, go,
objc, swift, javascript(-), typescript(+), and the venerable (but turing
complete ;-)) sql, so that might give you a sense of my bias.
Cheers
> 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).
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> 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
>>>>>>>>> [email protected]
>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
