Re: [swift-evolution] Winding down the Swift 3 release

[Eric Wing via swift-evolution]

On 5/16/16, Chris Lattner  wrote:
> On May 16, 2016, at 2:27 PM, Eric Wing via swift-evolution
>  wrote:
>>> I'm not an expert in the Linux communities needs and desires.  That
>>> said,
>>> from what I understand, they don’t care at all about ABI stability,
>>> since
>>> everything is typically built from source.
>>
>> Not exactly true. (I care.)
>>
>> Video games (e.g. Steam/Linux) care deeply about ABI stability. And
>> Android cares deeply about ABI stability. Also, kind of emergent
>> behavior, Raspberry Pi Raspbian has kind of built a platform that
>> happens to have some ABI stability for now.
>
> Great to know, and good point.  From that perspective, a Steam/Linux project
> would be in the same category as an iOS or Mac app: ABI stability doesn’t
> matter, so long as you include a copy of the swift standard library along
> with the steam app itself.  I know nothing about Steam, but it seems likely
> that this would have been a requirement anyway, because you can’t count on
> the standard library already existing.
>

Yes. I actually filed some bug reports a few weeks ago for
thoughts/concerns/issues related to this.

> ABI stability starts to matter when you’re interested in combining
> precompiled libraries built by different parties, which are only distributed
> in binary form.
>

That is what I’m working on. I also care about Mac and iOS.

Thanks,
Eric
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Thorsten Seitz via swift-evolution]

But don't you mean the union type of all possible Collection types when you 
write Any?

I suggested `all<>` for the intersection type, and `any<>` for the union type, 
so that would be the same, wouldn't it?

-Thorsten 

Am 17.05.2016 um 07:10 schrieb Brent Royal-Gordon via swift-evolution 
:

>> 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 have suggested `all<>` in the past, but I now favor `Any`, because that 
> allows it to be unified with the universal supertype `Any`, `Any`, and 
> things like `Any` to forge the One Existential Syntax to rule 
> them all.
> 
> -- 
> 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

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Brent Royal-Gordon via swift-evolution]

> 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 have suggested `all<>` in the past, but I now favor `Any`, because that 
allows it to be unified with the universal supertype `Any`, `Any`, and 
things like `Any` to forge the One Existential Syntax to rule them 
all.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Thorsten Seitz via swift-evolution]

> Am 16.05.2016 um 21:29 schrieb Thorsten Seitz via swift-evolution 
> :
> 
> 
>>> Am 15.05.2016 um 10:57 schrieb Adrian Zubarev via swift-evolution 
>>> :
>>> 
>>> I think an important point is that `all<>` should NOT be restricted to 
>>> having only one reference or value type!
>> 
>> This is a little problematic and I’m not a compiler expert so from my 
>> perspective I could allow that but in a different way you see it (I’ll 
>> explain below).
>> 
>>> Ceylon does not have any restrictions like that. You can form the type 
>>> intersection of String and Integer for example, which are both classes in 
>>> Ceylon and because Ceylon like Swift only knows single inheritance between 
>>> classes, the result is simply `Nothing` (the bottom type which has no 
>>> elements). So there is no need to forbid this explicitly, because the types 
>>> work out just fine.
>> 
>> If I remember correctly someone said that `Ceylon` does use `all` and `any` 
>> for its Optional?! We can’t to do this in Swift as far as I know our 
>> playground.
>> 
>> We don’t have `Nothing` in Swift. The counterpart would be `Optional` but 
>> such a type is made explicit by `?` symbol like `Type? == Optional` 
>> and the only equivalent to `Nothing` would be `nil`.
>> 
> `Nothing` is the bottom type, i.e. the intersection of all types. It has no 
> members.
> `Nothing` has nothing to do with optionals. Optionals in Ceylon are type 
> unions with the type `Null` which has a single member called `null` (= 
> Swift’s nil).
> 
> Maybe this proposal should start with forbidding creating `All<>` expressions 
> which would evaluate to `Nothing` and a later proposal could introduce the 
> bottom type.
> 
>> That been said, if `All<>` would always intersect (what I haven’t proposed 
>> here at all) we can’t replace `protocol<>` with `All<>` because if we look 
>> at two distinct protocols `A` and `B` and try to merge them into a type 
>> `All` would resolve in `implicit nil` where the old fashion way is not 
>> `protocol`.
>> 
> I don’t know from where you got `implicit nil`. Seems I was a bit unclear :-)
> All is the intersection type of A and B, i.e. a type which conforms to 
> A *and* B.
> Only for cases where A and B are *classes* which do *not* share an 
> inheritance relation the result of All is `Nothing` (the empty bottom 
> type). This is a special case. The reason is that because of single 
> inheritance it is impossible to define a subtype of two different class 
> hierarchies.
> If A and B are structs the result of All is `Nothing` as well, because 
> structs are not subtypeable at all. Note that All will just 
> be StructA, though.
> If at least one of A and B is a protocol it is always possible to define a 
> type that conforms to A and B.
> 
>> By the way, really an `implicit nil`? This is not a great idea if you ask 
>> me. 
>> 
>> You may have a look at this document: 
>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md
>> 
>> `All == implicit nil` (your way) while it probably `All> Int>? == nil` would serve your wished behavior, but again I wasn’t proposing 
>> on solving this issue here. I’d like to solve this problem 
>> https://openradar.appspot.com/20990743 and open the door for `AnyStruct`, 
>> `AnyEnum`, `AnyValue` (maybe `AnyTuple` someday). This is what your hint for 
>> `Any<>` combined with my `All<>` might create.
>> 
>> If we allow multiple reference and value types for `All<>` this will only 
>> work with subtypeable types, because as I already described above 
>> `All` can’t be merged.
>> 
> Yes, as long as subtyping structs is not possible in Swift All StructB> would be `Nothing` (again: this is not the type of `nil`).
> 
>> A scenario that will work might look like this:
>> 
>> class A {} class B: A {} class C: B {}
>> 
>> `All` from the given types and my understanding the compile could 
>> and should infer `C` from here (not `B` compared to your example below).
>> 
> 
> Oops, sorry, you are right. I again made the error of confusing intersection 
> types (all<>) with union types (any<>). Grrr. I’m used to the type operators, 
> that’s my only excuse…
> 
>> To sum up a little we would have these facts:
>> 
>> - for subtypeable types the compile will search the highest type from the 
>> inheritance path and ignore all other lower base types (for `All` the 
>> compile would infer `B == All == All`)
>> 
> With `highest` you mean `most specialized`, right? (for me that’s the lowest 
> type :-)
> 
>> - the oder of types should not matter because of the previous fact
>> 
> Exactly.
> 
>> That been said do we still need the whole inheritance branch inside of 
>> `All<>`? I don’t think so.
>> 
> Right, the whole branch is definitely not needed.
> 
>> Furthermore if we definitely should ignore order of `Types` 

[swift-evolution] [Proposal]Simple pattern matching with Horspool algorithm

[Susan Cheng via swift-evolution]

public extension CollectionType where Index : RandomAccessIndexType {



@warn_unused_result

func matchWith(pattern: C, @noescape
isEquivalent: (Generator.Element, Generator.Element) throws -> Bool)
rethrows -> Index? {



let pattern_count = pattern.count.toIntMax()

if count.toIntMax() < pattern_count {

return nil

}

let reverse_pattern = pattern.reverse()

var cursor = startIndex.advancedBy(numericCast(pattern_count - 1))

while cursor < endIndex {

let left = startIndex...cursor

let pair = zip(left.reverse(), reverse_pattern)

guard let not_match = try pair.firstOf({ try
!isEquivalent(self[$0],
$1) }) else {

return cursor.advancedBy(numericCast(1 - pattern_count))

}

if let pos = try reverse_pattern.dropFirst().indexOf({ try
isEquivalent(self[not_match.0], $0) }) {

let offset = reverse_pattern.startIndex.distanceTo(pos).
toIntMax()

cursor = not_match.0.advancedBy(numericCast(offset), limit:
endIndex)

} else {

cursor = not_match.0.advancedBy(numericCast(pattern_count),
limit: endIndex)

}

}

if try self.reverse().startsWith(reverse_pattern, isEquivalent:
isEquivalent) {

return endIndex.advancedBy(numericCast(-pattern_count))

}

return nil

}

}


public extension CollectionType where Index : RandomAccessIndexType,
Generator.Element : Equatable {



@warn_unused_result

func matchWith(pattern: C) -> Index? {

return self.matchWith(pattern) { $0 == $1 }

}

}


with this simplify version of Horspool algorithm, it can speed up searching
in any random access CollectionType (better than brute force searching).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Matt Whiteside via swift-evolution]

This sounds like a good idea.

-Matt

> On May 10, 2016, at 03:43, Geordie Jay via swift-evolution 
>  wrote:
> 
> 
>> Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution 
>> >:
>> 
>> 
>>> What is your evaluation of the proposal?
>> Personally I’m a -1; I’d prefer to see the NS prefix remain on types that 
>> have been translated automatically with minimal human interaction, in favour 
>> of dropping the prefix for types that have received more attention to 
>> establish a Swift-ier style, but migrating these into a new module instead.
> 
> I strongly agree with keeping NS prefix on API that has not been 
> ‘Swiftified'. First step, achieve functional equivalence with Darwin APIs. 
> Second step, systematically improve Foundation to the point where it feels 
> like this fundamental part of the language is as easy to use and idiomatic as 
> the standard library itself. At that point I’d be very much for dropping the 
> prefixes.
> 
>> 
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>> Since it’s a basic API that most developers will be interacting with then 
>> yes, even though the change is fairly minor, it definitely bears 
>> consideration.
>> 
>>> Does this proposal fit well with the feel and direction of Swift?
>> Yes and no. Prefixing types with NS definitely isn’t very Swift-y, but at 
>> the same time this is why I’d like to keep the current convention for 
>> existing (unchanged) types, as it makes it much clearer that these are 
>> things that weren’t originally designed for Swift and thus won’t behave 
>> quite as you might expect.
> 
> Completely agree
> 
>> 
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>> I’ve worked in languages where libraries had different styles of 
>> name-spacing, and while it was annoying to have a mixture, I think it was 
>> fine, especially for libraries that are older, as the prefix name-spacing 
>> style makes it absolutely clear that this is an older API.
>> 
> 
> Yes, we should be clear this is an older API, also to add motivation on 
> introducing a more modern one (even if at first it just wraps Foundation with 
> a more Swift-like API)
> 
>>> How much effort did you put into your review? A glance, a quick reading, or 
>>> an in-depth study?
>> 
>> Quick read of the proposal, kept an eye on the discussion leading up to it 
>> though.
>> ___
>> 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

Re: [swift-evolution] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

On May 16, 2016, at 9:03 PM, Haris Amin  wrote:
> Hey Chris and team,
> 
> This is great news. Any news on when/if libdispatch linux compatibility will 
> ship with Swift 3?

Hi Haris,

That is still the goal - I know that many folks are intensely interested in 
making this happen, and are contributing a lot of code (maybe one of them can 
comment?).  OTOH, while it looks promising, it still isn’t quite done.  :-)

-Chris


> 
> Thanks again.
> 
> Haris
> > Hi Everyone,
> > 
> > As we get deeper into the Swift 3 release cycle, we’re beginning to have a 
> > more precise understanding about what the release will shape up to be. Ted 
> > posted details of the Swift 3 release process last week 
> > (https://swift.org/blog/swift-3-0-release-process/ 
> > ) and I just updated the 
> > main swift-evolution README.md file 
> > (https://github.com/apple/swift-evolution 
> > ) with some updated details about 
> > the goals of Swift 3.
> > 
> > This release is shaping up to be a really phenomenal release that will 
> > redefine the feel of Swift and make a major leap towards maturing the Swift 
> > language and development experience. We have had a focus on getting to 
> > source stability, with the forward-looking goal of making Swift 4 as source 
> > compatible with Swift 3 as we can reasonably accomplish. It tackled API 
> > naming head on (which is one of the hardest problems in computer science 
> > [1]), made major improvements to the consistency and feel of the language, 
> > and has several nice across the board additions.
> > 
> > That said, it is also clear at this point that some of the loftier goals 
> > that we started out with aren’t going to fit into the release - including 
> > some of the most important generics features needed in order to lock down 
> > the ABI of the standard library. As such, the generics and ABI stability 
> > goals will roll into a future release of Swift, where I expect them to be 
> > the *highest* priority features to get done.
> > 
> > I expect discussion and planning for Swift 3.x and Swift 4 to start 
> > sometime around August of this year. Until then, it is very important that 
> > we as a community stay focused on the goals of Swift 3: I’d really prefer 
> > us all to resist the urge to discuss major blue sky features for future 
> > releases. We would also like to put a significant amount of effort into bug 
> > fixing and quality refinements as well, which means that the core team will 
> > be proactively deferring evolution proposals to later releases that don’t 
> > align with the Swift 3 goals, especially those that are strictly additive.
> > 
> > Thank you for all of the amazing community that has developed on this list, 
> > it is great to work with you all! Let us know if you have any questions,
> > 
> > -Chris
> > 
> > [1] It is well known that the two hard problems in Computer Science are 
> > naming, cache invalidation, and off-by-one errors.
> > 
> > 
> >

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Winding down the Swift 3 release

[Haris Amin via swift-evolution]

Hey Chris and team,

This is great news. Any news on when/if libdispatch linux compatibility
will ship with Swift 3?

Thanks again.

Haris
> Hi Everyone,
>
> As we get deeper into the Swift 3 release cycle, we’re beginning to have
a more precise understanding about what the release will shape up to be.
Ted posted details of the Swift 3 release process last week (
https://swift.org/blog/swift-3-0-release-process/) and I just updated the
main swift-evolution README.md file (
https://github.com/apple/swift-evolution) with some updated details about
the goals of Swift 3.
>
> This release is shaping up to be a really phenomenal release that will
redefine the feel of Swift and make a major leap towards maturing the Swift
language and development experience. We have had a focus on getting to
source stability, with the forward-looking goal of making Swift 4 as source
compatible with Swift 3 as we can reasonably accomplish. It tackled API
naming head on (which is one of the hardest problems in computer science
[1]), made major improvements to the consistency and feel of the language,
and has several nice across the board additions.
>
> That said, it is also clear at this point that some of the loftier goals
that we started out with aren’t going to fit into the release - including
some of the most important generics features needed in order to lock down
the ABI of the standard library. As such, the generics and ABI stability
goals will roll into a future release of Swift, where I expect them to be
the *highest* priority features to get done.
>
> I expect discussion and planning for Swift 3.x and Swift 4 to start
sometime around August of this year. Until then, it is very important that
we as a community stay focused on the goals of Swift 3: I’d really prefer
us all to resist the urge to discuss major blue sky features for future
releases. We would also like to put a significant amount of effort into bug
fixing and quality refinements as well, which means that the core team will
be proactively deferring evolution proposals to later releases that don’t
align with the Swift 3 goals, especially those that are strictly additive.
>
> Thank you for all of the amazing community that has developed on this
list, it is great to work with you all! Let us know if you have any
questions,
>
> -Chris
>
> [1] It is well known that the two hard problems in Computer Science are
naming, cache invalidation, and off-by-one errors.
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Removing "_ in" from empty closures

[Nicholas Maccharoli via swift-evolution]

+1


All the best,

Nicholas

Linked in:
http://lnkd.in/328U22


On Mon, May 16, 2016 at 7:27 AM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Fri May 13 2016, Joe Groff  wrote:
>
> >> On May 13, 2016, at 9:13 AM, Rob Napier via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> Currently if a closure takes a value, it requires "_ in" to note
> >> that the value is ignored. This makes sense in many cases, but
> >> creates a bit of a mess in the case of an empty, void-returning
> >
> >> closure:
> >>
> >> doThing(withCompletion: { _ in })
> >>
> >> I'd like to suggest that the compiler promote the empty closure
> >> literal {} to any void-returning closure type so that this could be
> >> written:
> >>
> >> doThing(withCompletion: {})
> >>
> >> This encourages the use of empty closures over optional closures,
> >> which I think is open for debate. In general I try to avoid
> >> optionals when they can be precisely replaced with a non-optional
> >> value. Furthermore, most Cocoa completion handlers are not optional.
> >>
> >> The alternative is to not do this, but encourage that any closure
> >> that could reasonably be empty should in fact be optional. I would
> >> then want Cocoa functions with void-returning closures to be
> >> imported as optionals to avoid "{ _ in }".
> >
> > +1. In general, I think we should allow implicit arguments, without
> > requiring the closure to use all the implicit $n variables like we do
> > today. These should all be valid:
> >
> > let _: () -> () = {}
> > let _: (Int) -> () = {}
> > let _: (Int, Int) -> Int = { 5 }
> > let _: (Int, Int) -> Int = { $0 }
> > let _: (Int, Int) -> Int = { $1 }
>
> +1
>
> --
> -Dave
>
> ___
> 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

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Dan Appel via swift-evolution]

-1 for all the reasons given so far. Foundation is not a Swift API and the
NS prefixes help users understand that. Until Foundation gets an API
rewrite that makes it feel native in the Swift ecosystem, it should be made
very clear that it is a legacy API and not necessary following Swift best
practices. I'm actually quite surprised that the Swift team decided to
reimplement Foundation with 100% api compatibility, rather than building a
"new and improved" version from scratch.

On Mon, May 16, 2016 at 6:37 PM Rob Mayoff via swift-evolution <
swift-evolution@swift.org> wrote:

> We (you) shouldn't remove the NS prefixes from most of the classes in
> the proposal. I agree with the reasons the other naysayers have given,
> but I'll try to restate them in my own words.
>
> Swift needs a better namespace/import system before these classes
> should lose the NS prefix. Right now, you cannot just import one name
> from a module. (If you think you can, try typing “import
> Foundation.NSDate; NSPort.self” into the REPL.) Therefore we should be
> selective about what loses the NS prefix.
>
> For any type, some fraction of programs need to mention the type by
> name in order to justify a prefixless name. What should that threshold
> be? Fifty percent? Ten percent? Five percent? String and Int and a
> bunch of other types in the standard library can pass a reasonable
> threshold. What fraction of programs mention NSTask? NSPort? NSHost?
> NSScanner?
>
> For any name, some fraction of programs would want to use that term
> for a program-specific type different than the Foundation type. What
> fraction is high enough to justify prefixing the Foundation type name?
> E.g. are there enough datebook programs that think "Calendar" should
> mean the user's schedule of events, so that Foundation shouldn't claim
> the generic term "Calendar"? How about "Timer"? "Task"? "Port"?
> "Host"?
>
> What fraction of these Foundation types would have a substantially
> different API if they were designed from scratch in the age of Swift
> with the experience of Foundation? Example: NSDate. Looking at each of
> JodaTime, NodaTime, and boost::date_time, I see a type representing a
> calendar date (e.g. 2016-05-16) with no associated time of day. I've
> seen and answered enough questions on stackoverflow to know that iOS
> programmers want a type like that. A from-scratch Swift date/time
> library would be justified in having such a type, and "Date" would be
> a great name for that type (with a prefix or nested in another type,
> unless Swift gets a better namespace/import system). NSDate represents
> the same thing as CFAbsoluteTime, and should have a name more
> representative of that.
>
> I just don't see the benefit of stripping the NS prefix from most of
> the types in Foundation, given the state of those types and the state
> of Swift.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Dan Appel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Rob Mayoff via swift-evolution]

We (you) shouldn't remove the NS prefixes from most of the classes in
the proposal. I agree with the reasons the other naysayers have given,
but I'll try to restate them in my own words.

Swift needs a better namespace/import system before these classes
should lose the NS prefix. Right now, you cannot just import one name
from a module. (If you think you can, try typing “import
Foundation.NSDate; NSPort.self” into the REPL.) Therefore we should be
selective about what loses the NS prefix.

For any type, some fraction of programs need to mention the type by
name in order to justify a prefixless name. What should that threshold
be? Fifty percent? Ten percent? Five percent? String and Int and a
bunch of other types in the standard library can pass a reasonable
threshold. What fraction of programs mention NSTask? NSPort? NSHost?
NSScanner?

For any name, some fraction of programs would want to use that term
for a program-specific type different than the Foundation type. What
fraction is high enough to justify prefixing the Foundation type name?
E.g. are there enough datebook programs that think "Calendar" should
mean the user's schedule of events, so that Foundation shouldn't claim
the generic term "Calendar"? How about "Timer"? "Task"? "Port"?
"Host"?

What fraction of these Foundation types would have a substantially
different API if they were designed from scratch in the age of Swift
with the experience of Foundation? Example: NSDate. Looking at each of
JodaTime, NodaTime, and boost::date_time, I see a type representing a
calendar date (e.g. 2016-05-16) with no associated time of day. I've
seen and answered enough questions on stackoverflow to know that iOS
programmers want a type like that. A from-scratch Swift date/time
library would be justified in having such a type, and "Date" would be
a great name for that type (with a prefix or nested in another type,
unless Swift gets a better namespace/import system). NSDate represents
the same thing as CFAbsoluteTime, and should have a name more
representative of that.

I just don't see the benefit of stripping the NS prefix from most of
the types in Foundation, given the state of those types and the state
of Swift.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Remove behavior on AnyObject that allows any obj-c method to be called on it

[Kevin Lundberg via swift-evolution]

I just saw these replies while searching for this thread, as I've been
thinking of this proposal again recently.

Regarding the API you point out, would it not be more appropriate for
the API to change to provide an object conforming to some protocol
definition instead? I don't like the idea of possible language changes
being held back just because of some poorly defined APIs that were
designed for a different language. Objective-C and cocoa frameworks have
been changing a lot in the past two years to better interoperate with
swift, and I don't see this example as something that needs to be
handled at all differently.

That said, if there are too many of these kinds of examples in Apple's
frameworks to completely resolve, would a more explicit use of the
feature be palatable? I mentioned in another branch of this thread that
if it is absolutely necessary to keep this behavior around, it could be
separated from AnyObject, perhaps into another protocol called something
like ObjcObject, so that code would need to do something like this to
compile and work:

let thing: ObjcObject = treeController.arrangedObjects()
let nodes = thing.childNodes?()

Unless theres a lot of pushback or it's too late for this kind of change
to go into Swift 3, I'd like to make some kind of proposal along these
lines.

- Kevin

On 4/18/2016 11:12 PM, Charles Srstka via swift-evolution wrote:
> Making things optional is fine; I would, however, like to give a
> strong -1 to the original proposal in which everything would have to
> be cast to an explicit type, since Cocoa contains APIs that give you
> objects of opaque types, returned as id/AnyObject, and expects you to
> be able to call methods on them. For example, -[NSTreeController
> arrangedObjects] returns an id/AnyObject which the documentation
> promises will respond to -childNodes and -descendantNodeAtIndexPath:,
> but no type information is given. If the original proposal were
> implemented, this API would become impossible to use from Swift.
>
> Charles
>
>> On Apr 18, 2016, at 10:01 PM, Joe Pamer via swift-evolution
>> > wrote:
>>
>> Just an update on this… (Sorry about the delay!)
>>
>> After experimenting with the changes outlined below, and discussing
>> the matter with a few folks off-list, it seems like a better
>> compromise would be to only adopt option #2. We would keep the direct
>> member access syntax and wrap the results of any dynamic member
>> access expressions in an Optional, as opposed to an IUO. In practice
>> this feels like a nice compromise that will prevent many users from
>> shooting themselves in the foot, as changing the wrapping to optional
>> forces users to immediately account for failures without having to
>> jump through too many hoops.
>>
>> Thoughts?
>>
>> Thanks!
>> - Joe
>>
>>> On Mar 23, 2016, at 12:45 PM, Joseph Pamer >> > wrote:
>>>
>>>
 On Mar 23, 2016, at 11:29 AM, Jordan Rose > wrote:

 The most common use case I've seen for this has been drilling into
 a heterogeneous collection without specifying intermediate types,
 i.e. `pluginProperties["actions"][0]["name"]`. Some possible
 variations on this proposal could continue to allow that:

 - Remove all lookup except the subscripts `(AnyObject) ->
 AnyObject?` and `(Int) -> AnyObject`.
 - Instead of removing AnyObject lookup completely (the proposal),
 change the IUO-wrapped results (the current behavior) to use
 Optional, requiring developers to explicitly deal with the
 possibility of failure.
 - Both of the above.

 I know Joe Pamer has been looking into seeing how this feature is
 used by introducing a warning for it in the type checker. Before
 making any changes here we'd want to know how it affects real-world
 projects.
>>>
>>> I should be pushing a branch that does both of the above “real soon
>>> now”. (This branch also includes my recent experiments in inhibiting
>>> implicit bridging conversions.) I’ll be curious to know what people
>>> think once they’ve had a chance to play with these changes.
>>>
>>> Thanks!
>>> - Joe
>>>

 Jordan


> On Mar 22, 2016, at 18:59 , Kevin Lundberg via swift-evolution
> > wrote:
>
> In "Using Swift with Cocoa and Objective-C", this behavior is
> described as part of how AnyObject works:
>
> /“You can also call any Objective-C method and access any property
> without casting to a more specific class type." … "However,
> because the specific type of an object typed as AnyObject is not
> known until runtime, it is possible to inadvertently write unsafe
> code. As in Objective-C, if you invoke a method or access a
> property that does not exist on an AnyObject typed object, it is a
> 

Re: [swift-evolution] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

On May 16, 2016, at 2:27 PM, Eric Wing via swift-evolution 
 wrote:
>> I'm not an expert in the Linux communities needs and desires.  That said,
>> from what I understand, they don’t care at all about ABI stability, since
>> everything is typically built from source.
> 
> Not exactly true. (I care.)
> 
> Video games (e.g. Steam/Linux) care deeply about ABI stability. And
> Android cares deeply about ABI stability. Also, kind of emergent
> behavior, Raspberry Pi Raspbian has kind of built a platform that
> happens to have some ABI stability for now.

Great to know, and good point.  From that perspective, a Steam/Linux project 
would be in the same category as an iOS or Mac app: ABI stability doesn’t 
matter, so long as you include a copy of the swift standard library along with 
the steam app itself.  I know nothing about Steam, but it seems likely that 
this would have been a requirement anyway, because you can’t count on the 
standard library already existing.

ABI stability starts to matter when you’re interested in combining precompiled 
libraries built by different parties, which are only distributed in binary form.

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

[Joe Groff via swift-evolution]

> On May 16, 2016, at 5:49 PM, Dan Appel  wrote:
> 
> Just to clarify: in your example, did you mean for DerivedA and DerivedB to 
> inherit from Base?

Yeah, sorry about that.

-Joe

> 
> On Mon, May 16, 2016 at 4:18 PM Matthew Johnson via swift-evolution 
>  wrote:
> +1
> 
> Sent from my iPhone
> 
> > On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution 
> >  wrote:
> >
> > Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what 
> > you'd expect, but does lead to problems when an 'as' expression appears as 
> > part of a comparison:
> >
> >20 as Int64 < y as Int64 // error, '>' expected to close generic 
> > parameter list Int64
> >
> > Looking to the future, many people have also expressed interest in the 
> > ability to do dynamic type checks against metatype values, not only static 
> > types, as in:
> >
> >class Base {}
> >class DerivedA {}
> >class DerivedB {}
> >
> >var x: Base.Type = DerivedA
> >
> >DerivedA() as? x // succeeds
> >DerivedB() as? x // fails
> >
> > If we accept 
> > https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md,
> >  dropping the '.self' requirement to refer to type objects, then I think we 
> > should also change 'is' and 'as' to parse the expression grammar on their 
> > right-hand side, leaving it up to the normal expression disambiguation rule 
> > to handle angle brackets. This solves the '20 as Int64 < x' problem, and 
> > prepares us to support dynamic is/as queries in the future. (To be clear, 
> > designing dynamic queries should be its own discussion.) What do you all 
> > think?
> >
> > -Joe
> > ___
> > 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
> -- 
> Dan Appel

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

[Dan Appel via swift-evolution]

Just to clarify: in your example, did you mean for DerivedA and DerivedB to
inherit from Base?

On Mon, May 16, 2016 at 4:18 PM Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

> +1
>
> Sent from my iPhone
>
> > On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what
> you'd expect, but does lead to problems when an 'as' expression appears as
> part of a comparison:
> >
> >20 as Int64 < y as Int64 // error, '>' expected to close generic
> parameter list Int64
> >
> > Looking to the future, many people have also expressed interest in the
> ability to do dynamic type checks against metatype values, not only static
> types, as in:
> >
> >class Base {}
> >class DerivedA {}
> >class DerivedB {}
> >
> >var x: Base.Type = DerivedA
> >
> >DerivedA() as? x // succeeds
> >DerivedB() as? x // fails
> >
> > If we accept
> https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md,
> dropping the '.self' requirement to refer to type objects, then I think we
> should also change 'is' and 'as' to parse the expression grammar on their
> right-hand side, leaving it up to the normal expression disambiguation rule
> to handle angle brackets. This solves the '20 as Int64 < x' problem, and
> prepares us to support dynamic is/as queries in the future. (To be clear,
> designing dynamic queries should be its own discussion.) What do you all
> think?
> >
> > -Joe
> > ___
> > 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
>
-- 
Dan Appel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

[Matthew Johnson via swift-evolution]

+1

Sent from my iPhone

> On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what you'd 
> expect, but does lead to problems when an 'as' expression appears as part of 
> a comparison:
> 
>20 as Int64 < y as Int64 // error, '>' expected to close generic parameter 
> list Int64
> 
> Looking to the future, many people have also expressed interest in the 
> ability to do dynamic type checks against metatype values, not only static 
> types, as in:
> 
>class Base {}
>class DerivedA {}
>class DerivedB {}
> 
>var x: Base.Type = DerivedA
> 
>DerivedA() as? x // succeeds
>DerivedB() as? x // fails
>
> If we accept 
> https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md,
>  dropping the '.self' requirement to refer to type objects, then I think we 
> should also change 'is' and 'as' to parse the expression grammar on their 
> right-hand side, leaving it up to the normal expression disambiguation rule 
> to handle angle brackets. This solves the '20 as Int64 < x' problem, and 
> prepares us to support dynamic is/as queries in the future. (To be clear, 
> designing dynamic queries should be its own discussion.) What do you all 
> think?
> 
> -Joe
> ___
> 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

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On May 16, 2016, at 8:16 PM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> 
>>> Am 16.05.2016 um 17:04 schrieb Karl via swift-evolution 
>>> :
>>> 
>>> internal func _arrayOutOfPlaceReplace
>>> 
>>> (_ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount: 
>>> Int)
>>> where
>>> C.Iterator.Element == B.Element,
>>> B.Index == Int
>>> {
>>> 
>>> Now only the relatively unimportant details—that the buffer and collection 
>>> must have elements of the same type, and that the buffer must have integer 
>>> indices—are at the end, whereas the basic conformances required to make any 
>>> sense at all of the declaration are still inline.
>> 
>> You see, I’m of the complete opposite opinion - I don’t think those details 
>> are “relatively unimportant”; I think they’re absolutely critical.
>> 
>> If you try and call it when your C.Iterator.Element is not equal to 
>> B.Element, the function does not exist. You’re talking about some other 
>> function in that case, not this one.
>> 
>> Same goes if B.Index is not an Int. If that was an unimportant detail, they 
>> would have given ‘bounds’ the type Range and not specified any 
>> constraints at all. The function requires the index be an Int - maybe it’s 
>> doing some mathematical operations which wouldn’t make sense for a more 
>> complex index type, such as DictionaryIndex.
>> 
>> Basically that is it - the ‘where’ clause is a vital part of the function 
>> declaration; it defines the specification under which the function exists at 
>> all (along with the function name, arguments and return type). If you don’t 
>> match every single part of that specification, the type checker won’t match 
>> your call to this function - if you don’t meet the constraints, you’re not 
>> talking about this function; imagine you have several overloaded function 
>> declarations which differ only by ‘where’ condition:
>> 
>> func insert(contentsOf:T) where T:RandomAccessCollection, T.Element == 
>> Element
>> func insert(contentsOf:T) where T:Collection, T.Element == Element
>> func insert(contentsOf:T) where T:Sequence, T.Element == Element
>> … etc
>> 
>> the ‘where’ clause isn’t incidental here - it’s the only disambiguating 
>> feature between these declarations. I think it’s critical information and 
>> shouldn’t be stuffed at the end because you think it’s not important; it is 
>> important. If it hinders initial readability of the declaration so much, you 
>> can wrap it behind a typealias:
>> 
>> func insert>(contentsOf: T)
>> func insert>(contentsOf: T)
>> func insert>(contentsOf: T)
>> … etc
> 
> Either you have the constraints first and the parameter list last or the 
> other way around. Fact is that *both* decide whether it is the function you 
> need.
> So just their order cannot help with that.
> I would still argue that the proposed version is more readable: just look at 
> your example above where the first part up to the where is identical at one 
> glance, so that the disambiguating part stands out whereas your other example 
> looks much more unstructured because of the different lengths of the generic 
> type list which makes the congruence of the parameter lists difficult to see 
> because they do not align anymore.
> 
>> 
>> I think that’s much easier to follow, and attempts to reduces the length and 
>> verbosity of the where clauses (i.e. like the fact that Collection’s 
>> associated type referring to its element is called ‘Element’; ‘CollectionOf’ 
>> encodes an equivalent constraint in less characters). This proposal just 
>> feels kind of lazy - we’ll just tack them on the end so we can ignore them a 
>> bit more easily, even though they’re still going to be monstrously long and 
>> difficult-to-read.
> 
> The typealias idea can be combined with the where clause at the end:
> 
> func insert(contentsOf:T) where T:RandomAccessCollectionOf
> func insert(contentsOf:T) where T:CollectionOf
> func insert(contentsOf:T) where T:SequenceOf
> 
> Much easier to discern (at least IMO) because everything is aligned.
> 
>> 
>> Are there any other languages that do this? Or anything even similar? It 
>> seems to me that the context-switching is something that human beings in 
>> general are not going to find very legible; like if you insert too many 
>> commas in a sentence.
> 
> Yes, Ceylon places all constraints (it only knows inheritance constraints) at 
> the end:
> 
> shared Value sum({Value+} values) 
> given Value satisfies Summable { ... }
> shared Item>[] zip({Key*} keys, {Item*} items)
> given Key satisfies Object
> given Item satisfies Object { ... }
> 
> It does the same for type definitions:
> shared class Singleton(Element element)
> extends Object()
> satisfies [Element+]
> given Element satisfies Object { ... }
> 

This confirms my impression that WHERE does not fit as well at the end as if 
the 

Re: [swift-evolution] Winding down the Swift 3 release

[John McCall via swift-evolution]

> On May 16, 2016, at 2:06 PM, Chris Lattner via swift-evolution 
>  wrote:
>> On May 16, 2016, at 11:33 AM, Tim Hawkins > > wrote:
>> 
>> At what point would you consider the Linux product to be viable for 
>> production server side application development. Do you think that goal has 
>> been achieved in swift 3.0. Or is it going to have to wait for the ABI lock 
>> down. 
>> 
> I'm not an expert in the Linux communities needs and desires.  That said, 
> from what I understand, they don’t care at all about ABI stability, since 
> everything is typically built from source.

I think it would be more appropriate to say that the server development 
community generally doesn't care deeply about ABI stability (although even 
there I'm sure there are exceptions).  There are a lot of client-side efforts 
that have very different requirements from that, though.

John.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] Amendment: SE-0039: Moderning Playground Literals

[John McCall via swift-evolution]

Original proposal:

  
https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md
 


Pull request for modification:

  https://github.com/apple/swift-evolution/pull/324 


Description

The Swift core team would like to amend this proposal to spell out what's 
happening with the literal protocols.  The proposal was not explicit about the 
fact that the protocols were going to change, and in fact it turned out that 
changing them was not a good idea.  We've already applied the effects of this 
amendment in trunk, but that is a decision that should be ratified by the 
community.  Please do not allow the fact that it's "already done" to discourage 
you from speaking up if you have strong feelings about this amendment.

The adjusted proposal fully specifies the "changes" to the object literal 
protocols.  I've put "changes" in quotes because, in fact, the result is no net 
change to the _ColorLiteralConvertible protocol vs. prior releases of Swift, 
and the other two protocols have been changed only to add "ResourceName" as a 
suffix to the argument label.  Adding this to the label is more explicit and 
may be useful if we choose to embellish these protocols in the future; it also 
creates a simple algorithm for deriving the initializer name from the name of 
the protocol and the argument labels in the literal.

These protocols are currently underscored and therefore are not intended to be 
implemented outside of the Swift repository, which is why I did not initially 
push this through review.

We view this as a minor amendment to the proposal.  The fast-track process for 
such amendments is to just open a pull request against the swift-evolution 
repository, which I've done and linked above.  Any necessary discussion should 
occur on that PR.  The core team will accept the PR after a reasonable amount 
of time unless there are strong objections; if there are, we will close the PR 
and start the ordinary evolution process.

John.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Winding down the Swift 3 release

[Charles Srstka via swift-evolution]

> On May 16, 2016, at 4:27 PM, Eric Wing via swift-evolution 
>  wrote:
> 
>> I'm not an expert in the Linux communities needs and desires.  That said,
>> from what I understand, they don’t care at all about ABI stability, since
>> everything is typically built from source.
>> 
>> -Chris
>> 
>> 
> 
> Not exactly true. (I care.)
> 
> Video games (e.g. Steam/Linux) care deeply about ABI stability. And
> Android cares deeply about ABI stability. Also, kind of emergent
> behavior, Raspberry Pi Raspbian has kind of built a platform that
> happens to have some ABI stability for now.
> 
> Thanks,
> Eric

ABI stability is also central to eventually removing the need to always ship 
the runtime along with our binaries.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Winding down the Swift 3 release

[Eric Wing via swift-evolution]

> I'm not an expert in the Linux communities needs and desires.  That said,
> from what I understand, they don’t care at all about ABI stability, since
> everything is typically built from source.
>
> -Chris
>
>

Not exactly true. (I care.)

Video games (e.g. Steam/Linux) care deeply about ABI stability. And
Android cares deeply about ABI stability. Also, kind of emergent
behavior, Raspberry Pi Raspbian has kind of built a platform that
happens to have some ABI stability for now.

Thanks,
Eric
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

[Timothy Wood via swift-evolution]

> On May 16, 2016, at 2:06 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> Looking to the future, many people have also expressed interest in the 
> ability to do dynamic type checks against metatype values, not only static 
> types, as in:

+1 -- I’ve definitely needed this before, and ended up having to escape out to 
Obj-C (which worked for my particular case, but maybe wouldn’t have if the type 
I wanted to check against was a Swift protocol?).

-tim

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

[David Sweeris via swift-evolution]

+1

- Dave Sweeris

> On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what you'd 
> expect, but does lead to problems when an 'as' expression appears as part of 
> a comparison:
> 
>   20 as Int64 < y as Int64 // error, '>' expected to close generic 
> parameter list Int64
> 
> Looking to the future, many people have also expressed interest in the 
> ability to do dynamic type checks against metatype values, not only static 
> types, as in:
> 
>   class Base {}
>   class DerivedA {}
>   class DerivedB {}
> 
>   var x: Base.Type = DerivedA
> 
>   DerivedA() as? x // succeeds
>   DerivedB() as? x // fails
>   
> If we accept 
> https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md,
>  dropping the '.self' requirement to refer to type objects, then I think we 
> should also change 'is' and 'as' to parse the expression grammar on their 
> right-hand side, leaving it up to the normal expression disambiguation rule 
> to handle angle brackets. This solves the '20 as Int64 < x' problem, and 
> prepares us to support dynamic is/as queries in the future. (To be clear, 
> designing dynamic queries should be its own discussion.) What do you all 
> think?
> 
> -Joe
> ___
> 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

Re: [swift-evolution] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

On May 16, 2016, at 12:29 PM, Dan Stenmark  wrote:
> With the generics and ABI stability goals getting pushed out to a future 
> release, how does that affect the plans for Swift concurrency features?  Will 
> the topic still be explored in the Swift 4 timeframe, or do you expect that 
> discussion be deferred to 5 or beyond?

I expect us to discuss what goes into post-Swift-3.0 release in ~August this 
year.  I’m sure that many folks will be interested in this and many other 
topics.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

> On May 16, 2016, at 11:53 AM, Ryan Lovelett  
> wrote:
> 
> On Mon, May 16, 2016, at 11:18 AM, Chris Lattner via swift-evolution
> wrote:
>> Hi Everyone,
>> 
>> As we get deeper into the Swift 3 release cycle, we’re beginning to have
>> a more precise understanding about what the release will shape up to be. 
>> Ted posted details of the Swift 3 release process last week
>> (https://swift.org/blog/swift-3-0-release-process/) and I just updated
>> the main swift-evolution README.md file
>> (https://github.com/apple/swift-evolution) with some updated details
>> about the goals of Swift 3.
> 
> I noticed this comment on Hacker News:
> https://news.ycombinator.com/item?id=11708052
> 
> The comment brought up a question about the "Portability" section
> disappearing from the README. Until reading that comment I had not
> noticed the removal of the goal. But upon examination I would like to
> know what the implication of that removal is.
> 
> Would you mind expanding on the implications of that section
> disappearing? Just an accidental omission? Is portability now considered
> done/achieved? Or are the core team members throwing in the towel on
> that goal? (Perhaps it is some variation on those themes or something
> completely different)

Portability is still a strong goal, I will add it back, thank you for raising 
this!

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

[Joe Groff via swift-evolution]

Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what you'd 
expect, but does lead to problems when an 'as' expression appears as part of a 
comparison:

20 as Int64 < y as Int64 // error, '>' expected to close generic 
parameter list Int64

Looking to the future, many people have also expressed interest in the ability 
to do dynamic type checks against metatype values, not only static types, as in:

class Base {}
class DerivedA {}
class DerivedB {}

var x: Base.Type = DerivedA

DerivedA() as? x // succeeds
DerivedB() as? x // fails

If we accept 
https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md,
 dropping the '.self' requirement to refer to type objects, then I think we 
should also change 'is' and 'as' to parse the expression grammar on their 
right-hand side, leaving it up to the normal expression disambiguation rule to 
handle angle brackets. This solves the '20 as Int64 < x' problem, and prepares 
us to support dynamic is/as queries in the future. (To be clear, designing 
dynamic queries should be its own discussion.) What do you all think?

-Joe
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

> On May 16, 2016, at 11:33 AM, Tim Hawkins  wrote:
> 
> At what point would you consider the Linux product to be viable for 
> production server side application development. Do you think that goal has 
> been achieved in swift 3.0. Or is it going to have to wait for the ABI lock 
> down. 
> 
I'm not an expert in the Linux communities needs and desires.  That said, from 
what I understand, they don’t care at all about ABI stability, since everything 
is typically built from source.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0092: Typealiases in protocols and protocol extensions

[Chris Lattner via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md

The new proposal for SE-0092 "Typealiases in protocols and protocol extensions” 
is proactively approved for Swift.  The core team consider this as an obvious 
follow-on to SE-0011, and thus doesn’t itself demand a proposal.  However, 
including a proposal in the swift-evolution archive does have a benefit to keep 
track of the new capability it enables.

The core team accepted this without a formal review period (because it its 
obviousness) as an attempt to optimize process.  If there are any serious 
concerns, please raise them and we are happy to reconsider and start a normal 
review cycle.

I filed SR-1539 to track this effort.  Thank you to David Hart and Doug Gregor 
for the proposal, and to Greg Titus
for already starting the implementation work on this!

-Chris Lattner
Review Manager

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Idea: Named extensions

[Brandon Knope via swift-evolution]

Ya I didn’t see that email until after I wrote it up. If it does gain traction, 
I wouldn’t mind writing a proposal and tabling it for now. 

Would just like to see some discussion on it, but I don’t want to detract from 
the current goals!

Brandon

> On May 16, 2016, at 4:25 PM, T.J. Usiyan  wrote:
> 
> I have wanted this feature and floated it a while back. I hope we can get 
> some traction this time but I doubt it will happen soon since additive 
> features are tabled for a time.
> 
> On Mon, May 16, 2016 at 3:47 PM, Brandon Knope via swift-evolution 
> > wrote:
> I think requiring them to be in comments is what’s going to prevent their 
> adoption.
> 
> My fundamental stance is that these awesome features that are required in 
> comments will be overlooked by people because:
> • You have to remember the specific syntax 
> • There is no code completion which means you have to know the *exact* syntax 
> and spelling
> 
> At the end of the day, Swift is a new language, and because of this, is there 
> a new and better way to convey information than just sticking everything in a 
> comment?
> 
> With autocomplete we could get something like this:
> 
> extension Type, named Name {
> }
> 
> This would make it much easier for people to adopt than requiring them to 
> remember a comment syntax.
> 
> However, if there is no interest, I will not proceed with a proposal.
> 
> Just my .02
> Brandon
> 
> Where autocomplete would let you tab between naming the Type and Name
> 
>> On May 16, 2016, at 3:24 PM, Erica Sadun > > wrote:
>> 
>> Most of the Swift docs markup tech is both very new and still evolving. I'm 
>> trying to evangelize the technology, and there are now five markup items 
>> that actually tie into the code completion engine:
>> 
>> Three new doc comment fields, namely - keyword:, - recommended: and - 
>> recommendedover:, allow Swift users to cooperate with code completion engine 
>> to deliver more effective code completion results. The - keyword: field 
>> specifies concepts that are not fully manifested in declaration names. - 
>> recommended: indicates other declarations are preferred to the one 
>> decorated; to the contrary, - recommendedover: indicates the decorated 
>> declaration is preferred to those declarations whose names are specified.
>> 
>> -- E
>> 
>> 
>>> On May 16, 2016, at 1:14 PM, Brandon Knope >> > wrote:
>>> 
>>> I have never seen anyone use this. Why? Because it is relatively unknown 
>>> and not very “pretty” in my opinion. In the ideal world, everyone would 
>>> have perfectly formatted and up to date comment, but I am not convinced 
>>> this is usually the case.
>>> 
>>> It’s good for IDE documenting, but:
>>> • Online tutorials do NOT use this in code samples, keeping it from being 
>>> widely known (and because it looks ugly next to their sample and makes it 
>>> look more verbose)
>>> • It really does not look nice with the language. It seems like IDE magic
>>> • What about people writing in a text editor or not in Xcode? If they do 
>>> not get a benefit out of // MARK: or /// - Keyword: why would they use it?
>>> 
>>> And a quick read of Matthew’s proposal tells me that it may be beneficial 
>>> to be able to refer to the name of an extension in the future. I am still 
>>> reading through his proposal but that’s what I took from it with a quick 
>>> look.
>>> 
>>> 
>>> Brandon
>>> 
 On May 16, 2016, at 3:08 PM, Erica Sadun > wrote:
 
 Or better yet, the 'Keyword" token offers searchable content that can 
 relate one extension to the other.
 
 /// - Keyword: Lifecycle extension
 
 -- Erica
 
 
> On May 16, 2016, at 11:33 AM, Michael Peternell via swift-evolution 
> > wrote:
> 
> Why not just use a (documentation) comment?
> 
> /// The Lifecycle extension:
> extension ViewController {
> ...
> 
> -Michael
> 
>> Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution 
>> >:
>> 
>> I like to separate methods into their own logical extensions so similar 
>> methods are grouped together. I do this mostly with Cocoa Touch where I 
>> like all view life cycle methods to be in the same extension:
>> 
>> extension ViewController {
>>  override func viewDidLoad() {
>>  }
>> 
>>  override func viewWillAppear(animated: Bool) {
>>  }
>> 
>>  override func viewDidDisappear(animated: Bool) {
>>  }
>> }
>> 
>> You can document this somewhat by adding a MARK comment:
>> 
>> // MARK: Lifecylce
>> extension ViewController {
>>  override func viewDidLoad() {

Re: [swift-evolution] Idea: Named extensions

[Brandon Knope via swift-evolution]

Here is an attempt to express myself better :)

Objective-C to Swift category to extension conversion loss of descriptive name

Objective-C category:
@interface NSAttributedString (NSAttributedStringDocumentFormats)
// Methods initializing the receiver contents with an external document data.  
options specify document attributes for interpreting the document contents.  
NSDocumentTypeDocumentAttribute, NSCharacterEncodingDocumentAttribute, and 
NSDefaultAttributesDocumentAttribute are supported options key.  When they are 
not specified, these methods will examine the data and do their best to detect 
the appropriate attributes.  If dict is non-NULL, it will return a dictionary 
with various document-wide attributes accessible via NS...DocumentAttribute 
keys.
- (nullable instancetype)initWithURL:(NSURL *)url 
options:(NSDictionary *)options 
documentAttributes:(NSDictionary * __nullable * __nullable)dict 
error:(NSError **)error NS_AVAILABLE(10_11, 9_0);

...
@end

Translated Swift extension:
extension NSAttributedString {
// Methods initializing the receiver contents with an external document 
data.  options specify document attributes for interpreting the document 
contents.  NSDocumentTypeDocumentAttribute, 
NSCharacterEncodingDocumentAttribute, and NSDefaultAttributesDocumentAttribute 
are supported options key.  When they are not specified, these methods will 
examine the data and do their best to detect the appropriate attributes.  If 
dict is non-NULL, it will return a dictionary with various document-wide 
attributes accessible via NS...DocumentAttribute keys.
@available(iOS 9.0, *)
public init(URL url: NSURL, options: [String : AnyObject], 
documentAttributes dict: AutoreleasingUnsafeMutablePointer) 
throws
...
}


The self-documenting name of the category is lost when imported in Swift. Some 
categories have no outward comment describing it because they seem to rely on 
the category name. For example, this one *does* have a comment describing it 
that is imported into swift:


Objective-C
/ Attribute fixing /

@interface NSMutableAttributedString (NSAttributedStringAttributeFixing)

@end


Swift:
/ Attribute fixing /
extension NSMutableAttributedString {

}

Again, the comment is not enforced by the compiler and is a style choice. Names 
on categories are enforced (except for a class’s private () category)

One moonshot: Are extension’s an implementation detail?

Here is the generated interface for a simple View Controller

internal class ViewController : UIViewController {

override internal func viewDidLoad()

override internal func didReceiveMemoryWarning()
}

extension ViewController {

internal func test()
}

Theoretically, if we had named extensions:

extension ViewController named Test {
 internal func test() {

}
}

could be translated to:

internal class ViewController : UIViewController {

override internal func viewDidLoad()

override internal func didReceiveMemoryWarning()

Test:
internal func test()

}

I am not sure if this behavior would be truly desired, but it would allow the 
methods to remained group under a comment or a header of some sort.

//Phew
Brandon

> On May 16, 2016, at 4:25 PM, T.J. Usiyan  wrote:
> 
> I have wanted this feature and floated it a while back. I hope we can get 
> some traction this time but I doubt it will happen soon since additive 
> features are tabled for a time.
> 
> On Mon, May 16, 2016 at 3:47 PM, Brandon Knope via swift-evolution 
> > wrote:
> I think requiring them to be in comments is what’s going to prevent their 
> adoption.
> 
> My fundamental stance is that these awesome features that are required in 
> comments will be overlooked by people because:
> • You have to remember the specific syntax 
> • There is no code completion which means you have to know the *exact* syntax 
> and spelling
> 
> At the end of the day, Swift is a new language, and because of this, is there 
> a new and better way to convey information than just sticking everything in a 
> comment?
> 
> With autocomplete we could get something like this:
> 
> extension Type, named Name {
> }
> 
> This would make it much easier for people to adopt than requiring them to 
> remember a comment syntax.
> 
> However, if there is no interest, I will not proceed with a proposal.
> 
> Just my .02
> Brandon
> 
> Where autocomplete would let you tab between naming the Type and Name
> 
>> On May 16, 2016, at 3:24 PM, Erica Sadun > > wrote:
>> 
>> Most of the Swift docs markup tech is both very new and still evolving. I'm 
>> trying to evangelize the technology, and there are now five markup items 
>> that actually tie into the code completion engine:
>> 
>> Three new doc comment fields, namely 

Re: [swift-evolution] Idea: Named extensions

[T.J. Usiyan via swift-evolution]

I have wanted this feature and floated it a while back. I hope we can get
some traction this time but I doubt it will happen soon since additive
features are tabled for a time.

On Mon, May 16, 2016 at 3:47 PM, Brandon Knope via swift-evolution <
swift-evolution@swift.org> wrote:

> I think requiring them to be in comments is what’s going to prevent their
> adoption.
>
> My fundamental stance is that these awesome features that are required in
> comments will be overlooked by people because:
> • You have to remember the specific syntax
> • There is no code completion which means you have to know the *exact*
> syntax and spelling
>
> At the end of the day, Swift is a new language, and because of this, is
> there a new and better way to convey information than just sticking
> everything in a comment?
>
> With autocomplete we could get something like this:
>
> extension *Type,* named *Name* {
> }
>
> This would make it much easier for people to adopt than requiring them to
> remember a comment syntax.
>
> However, if there is no interest, I will not proceed with a proposal.
>
> Just my .02
> Brandon
>
> Where autocomplete would let you tab between naming the Type and Name
>
> On May 16, 2016, at 3:24 PM, Erica Sadun  wrote:
>
> Most of the Swift docs markup tech is both very new and still evolving.
> I'm trying to evangelize the technology, and there are now five markup
> items that actually tie into the code completion engine:
>
>
>-
>
>Three new doc comment fields, namely - keyword:, - recommended: and -
>recommendedover:, allow Swift users to cooperate with code completion
>engine to deliver more effective code completion results. The -
>keyword: field specifies concepts that are not fully manifested in
>declaration names. - recommended: indicates other declarations are
>preferred to the one decorated; to the contrary, - recommendedover: 
> indicates
>the decorated declaration is preferred to those declarations whose names
>are specified.
>
> -- E
>
>
> On May 16, 2016, at 1:14 PM, Brandon Knope  wrote:
>
> I have never seen anyone use this. Why? Because it is relatively unknown
> and not very “pretty” in my opinion. In the ideal world, everyone would
> have perfectly formatted and up to date comment, but I am not convinced
> this is usually the case.
>
> It’s good for IDE documenting, but:
> • Online tutorials do NOT use this in code samples, keeping it from being
> widely known (and because it looks ugly next to their sample and makes it
> look more verbose)
> • It really does not look nice with the language. It seems like IDE magic
> • What about people writing in a text editor or not in Xcode? If they do
> not get a benefit out of // MARK: or /// - Keyword: why would they use it?
>
> And a quick read of Matthew’s proposal tells me that it may be beneficial
> to be able to refer to the name of an extension in the future. I am still
> reading through his proposal but that’s what I took from it with a quick
> look.
>
>
> Brandon
>
> On May 16, 2016, at 3:08 PM, Erica Sadun  wrote:
>
> Or better yet, the 'Keyword" token offers searchable content that can
> relate one extension to the other.
>
> /// - Keyword: Lifecycle extension
>
> -- Erica
>
>
> On May 16, 2016, at 11:33 AM, Michael Peternell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Why not just use a (documentation) comment?
>
> /// The Lifecycle extension:
> extension ViewController {
> ...
>
> -Michael
>
> Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution <
> swift-evolution@swift.org>:
>
> I like to separate methods into their own logical extensions so similar
> methods are grouped together. I do this mostly with Cocoa Touch where I
> like all view life cycle methods to be in the same extension:
>
> extension ViewController {
>  override func viewDidLoad() {
>  }
>
>  override func viewWillAppear(animated: Bool) {
>  }
>
>  override func viewDidDisappear(animated: Bool) {
>  }
> }
>
> You can document this somewhat by adding a MARK comment:
>
> // MARK: Lifecylce
> extension ViewController {
>  override func viewDidLoad() {
>  }
>
>  override func viewWillAppear(animated: Bool) {
>  }
>
>  override func viewDidDisappear(animated: Bool) {
>  }
> }
>
> What if we made this more self-documenting by elevating this to a language
> feature?
>
> extension ViewController named Lifecycle {
>  override func viewDidLoad() {
>  }
>
>  override func viewWillAppear(animated: Bool) {
>  }
>
>  override func viewDidDisappear(animated: Bool) {
>  }
> }
>
> Other ways:
> extension named Lifecycle ViewController { }
> extension named “View Lifecycle" ViewController { }
> extension ViewController named “Multi word description” { }
>
>
> For now, this is purely a documenting feature (i.e. Can’t refer to the
> extension name dynamically or statically in actual code). I think it plays
> much more naturally with Swift than requiring this to be 

Re: [swift-evolution] Idea: Named extensions

[Brandon Knope via swift-evolution]

I think requiring them to be in comments is what’s going to prevent their 
adoption.

My fundamental stance is that these awesome features that are required in 
comments will be overlooked by people because:
• You have to remember the specific syntax 
• There is no code completion which means you have to know the *exact* syntax 
and spelling

At the end of the day, Swift is a new language, and because of this, is there a 
new and better way to convey information than just sticking everything in a 
comment?

With autocomplete we could get something like this:

extension Type, named Name {
}

This would make it much easier for people to adopt than requiring them to 
remember a comment syntax.

However, if there is no interest, I will not proceed with a proposal.

Just my .02
Brandon

Where autocomplete would let you tab between naming the Type and Name

> On May 16, 2016, at 3:24 PM, Erica Sadun  wrote:
> 
> Most of the Swift docs markup tech is both very new and still evolving. I'm 
> trying to evangelize the technology, and there are now five markup items that 
> actually tie into the code completion engine:
> 
> Three new doc comment fields, namely - keyword:, - recommended: and - 
> recommendedover:, allow Swift users to cooperate with code completion engine 
> to deliver more effective code completion results. The - keyword: field 
> specifies concepts that are not fully manifested in declaration names. - 
> recommended: indicates other declarations are preferred to the one decorated; 
> to the contrary, - recommendedover: indicates the decorated declaration is 
> preferred to those declarations whose names are specified.
> 
> -- E
> 
> 
>> On May 16, 2016, at 1:14 PM, Brandon Knope > > wrote:
>> 
>> I have never seen anyone use this. Why? Because it is relatively unknown and 
>> not very “pretty” in my opinion. In the ideal world, everyone would have 
>> perfectly formatted and up to date comment, but I am not convinced this is 
>> usually the case.
>> 
>> It’s good for IDE documenting, but:
>> • Online tutorials do NOT use this in code samples, keeping it from being 
>> widely known (and because it looks ugly next to their sample and makes it 
>> look more verbose)
>> • It really does not look nice with the language. It seems like IDE magic
>> • What about people writing in a text editor or not in Xcode? If they do not 
>> get a benefit out of // MARK: or /// - Keyword: why would they use it?
>> 
>> And a quick read of Matthew’s proposal tells me that it may be beneficial to 
>> be able to refer to the name of an extension in the future. I am still 
>> reading through his proposal but that’s what I took from it with a quick 
>> look.
>> 
>> 
>> Brandon
>> 
>>> On May 16, 2016, at 3:08 PM, Erica Sadun >> > wrote:
>>> 
>>> Or better yet, the 'Keyword" token offers searchable content that can 
>>> relate one extension to the other.
>>> 
>>> /// - Keyword: Lifecycle extension
>>> 
>>> -- Erica
>>> 
>>> 
 On May 16, 2016, at 11:33 AM, Michael Peternell via swift-evolution 
 > wrote:
 
 Why not just use a (documentation) comment?
 
 /// The Lifecycle extension:
 extension ViewController {
 ...
 
 -Michael
 
> Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution 
> >:
> 
> I like to separate methods into their own logical extensions so similar 
> methods are grouped together. I do this mostly with Cocoa Touch where I 
> like all view life cycle methods to be in the same extension:
> 
> extension ViewController {
>  override func viewDidLoad() {
>  }
> 
>  override func viewWillAppear(animated: Bool) {
>  }
> 
>  override func viewDidDisappear(animated: Bool) {
>  }
> }
> 
> You can document this somewhat by adding a MARK comment:
> 
> // MARK: Lifecylce
> extension ViewController {
>  override func viewDidLoad() {
>  }
> 
>  override func viewWillAppear(animated: Bool) {
>  }
> 
>  override func viewDidDisappear(animated: Bool) {
>  }
> }
> 
> What if we made this more self-documenting by elevating this to a 
> language feature?
> 
> extension ViewController named Lifecycle {
>  override func viewDidLoad() {
>  }
> 
>  override func viewWillAppear(animated: Bool) {
>  }
> 
>  override func viewDidDisappear(animated: Bool) {
>  }
> }
> 
> Other ways:
> extension named Lifecycle ViewController { }
> extension named “View Lifecycle" ViewController { }
> extension ViewController named “Multi word description” { }
> 
> 
> For now, this is purely a documenting feature (i.e. Can’t refer to the 
> extension name 

Re: [swift-evolution] Winding down the Swift 3 release

[Dan Stenmark via swift-evolution]

With the generics and ABI stability goals getting pushed out to a future 
release, how does that affect the plans for Swift concurrency features?  Will 
the topic still be explored in the Swift 4 timeframe, or do you expect that 
discussion be deferred to 5 or beyond?

Dan

> On May 16, 2016, at 8:18 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hi Everyone,
> 
> As we get deeper into the Swift 3 release cycle, we’re beginning to have a 
> more precise understanding about what the release will shape up to be.  Ted 
> posted details of the Swift 3 release process last week 
> (https://swift.org/blog/swift-3-0-release-process/) and I just updated the 
> main swift-evolution README.md file 
> (https://github.com/apple/swift-evolution) with some updated details about 
> the goals of Swift 3.
> 
> This release is shaping up to be a really phenomenal release that will 
> redefine the feel of Swift and make a major leap towards maturing the Swift 
> language and development experience.  We have had a focus on getting to 
> source stability, with the forward-looking goal of making Swift 4 as source 
> compatible with Swift 3 as we can reasonably accomplish.  It tackled API 
> naming head on (which is one of the hardest problems in computer science 
> [1]), made major improvements to the consistency and feel of the language, 
> and has several nice across the board additions.
> 
> That said, it is also clear at this point that some of the loftier goals that 
> we started out with aren’t going to fit into the release - including some of 
> the most important generics features needed in order to lock down the ABI of 
> the standard library. As such, the generics and ABI stability goals will roll 
> into a future release of Swift, where I expect them to be the *highest* 
> priority features to get done.
> 
> I expect discussion and planning for Swift 3.x and Swift 4 to start sometime 
> around August of this year.  Until then, it is very important that we as a 
> community stay focused on the goals of Swift 3: I’d really prefer us all to 
> resist the urge to discuss major blue sky features for future releases.  We 
> would also like to put a significant amount of effort into bug fixing and 
> quality refinements as well, which means that the core team will be 
> proactively deferring evolution proposals to later releases that don’t align 
> with the Swift 3 goals, especially those that are strictly additive.
> 
> Thank you for all of the amazing community that has developed on this list, 
> it is great to work with you all!  Let us know if you have any questions,
> 
> -Chris
> 
> [1] It is well known that the two hard problems in Computer Science are 
> naming, cache invalidation, and off-by-one errors.
> ___
> 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

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Thorsten Seitz via swift-evolution]

> Am 15.05.2016 um 10:57 schrieb Adrian Zubarev via swift-evolution 
> :
> 
>> I think an important point is that `all<>` should NOT be restricted to 
>> having only one reference or value type!
> 
> This is a little problematic and I’m not a compiler expert so from my 
> perspective I could allow that but in a different way you see it (I’ll 
> explain below).
> 
>> Ceylon does not have any restrictions like that. You can form the type 
>> intersection of String and Integer for example, which are both classes in 
>> Ceylon and because Ceylon like Swift only knows single inheritance between 
>> classes, the result is simply `Nothing` (the bottom type which has no 
>> elements). So there is no need to forbid this explicitly, because the types 
>> work out just fine.
> 
> If I remember correctly someone said that `Ceylon` does use `all` and `any` 
> for its Optional?! We can’t to do this in Swift as far as I know our 
> playground.
> 
> We don’t have `Nothing` in Swift. The counterpart would be `Optional` but 
> such a type is made explicit by `?` symbol like `Type? == Optional` and 
> the only equivalent to `Nothing` would be `nil`.
> 
`Nothing` is the bottom type, i.e. the intersection of all types. It has no 
members.
`Nothing` has nothing to do with optionals. Optionals in Ceylon are type unions 
with the type `Null` which has a single member called `null` (= Swift’s nil).

Maybe this proposal should start with forbidding creating `All<>` expressions 
which would evaluate to `Nothing` and a later proposal could introduce the 
bottom type.

> That been said, if `All<>` would always intersect (what I haven’t proposed 
> here at all) we can’t replace `protocol<>` with `All<>` because if we look at 
> two distinct protocols `A` and `B` and try to merge them into a type `All B>` would resolve in `implicit nil` where the old fashion way is not 
> `protocol`.
> 
I don’t know from where you got `implicit nil`. Seems I was a bit unclear :-)
All is the intersection type of A and B, i.e. a type which conforms to A 
*and* B.
Only for cases where A and B are *classes* which do *not* share an inheritance 
relation the result of All is `Nothing` (the empty bottom type). This is 
a special case. The reason is that because of single inheritance it is 
impossible to define a subtype of two different class hierarchies.
If A and B are structs the result of All is `Nothing` as well, because 
structs are not subtypeable at all. Note that All will just 
be StructA, though.
If at least one of A and B is a protocol it is always possible to define a type 
that conforms to A and B.

> By the way, really an `implicit nil`? This is not a great idea if you ask me. 
> 
> You may have a look at this document: 
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md 
> 
> `All == implicit nil` (your way) while it probably `All Int>? == nil` would serve your wished behavior, but again I wasn’t proposing 
> on solving this issue here. I’d like to solve this problem 
> https://openradar.appspot.com/20990743 
>  and open the door for `AnyStruct`, 
> `AnyEnum`, `AnyValue` (maybe `AnyTuple` someday). This is what your hint for 
> `Any<>` combined with my `All<>` might create.
> 
> If we allow multiple reference and value types for `All<>` this will only 
> work with subtypeable types, because as I already described above 
> `All` can’t be merged.
> 
Yes, as long as subtyping structs is not possible in Swift All would be `Nothing` (again: this is not the type of `nil`).

> A scenario that will work might look like this:
> 
> class A {} class B: A {} class C: B {}
> 
> `All` from the given types and my understanding the compile could 
> and should infer `C` from here (not `B` compared to your example below).
> 
> 

Oops, sorry, you are right. I again made the error of confusing intersection 
types (all<>) with union types (any<>). Grrr. I’m used to the type operators, 
that’s my only excuse…

> To sum up a little we would have these facts:
> 
> - for subtypeable types the compile will search the highest type from the 
> inheritance path and ignore all other lower base types (for `All` the 
> compile would infer `B == All == All`)
> 
With `highest` you mean `most specialized`, right? (for me that’s the lowest 
type :-)

> - the oder of types should not matter because of the previous fact
> 
Exactly.

> That been said do we still need the whole inheritance branch inside of 
> `All<>`? I don’t think so.
> 
Right, the whole branch is definitely not needed.

> Furthermore if we definitely should ignore order of `Types` inside the angle 
> brackets like `All == All`, because it makes sense from the 
> context of creating a `Type` that is constrained to 

Re: [swift-evolution] Idea: Named extensions

[Erica Sadun via swift-evolution]

Most of the Swift docs markup tech is both very new and still evolving. I'm 
trying to evangelize the technology, and there are now five markup items that 
actually tie into the code completion engine:

Three new doc comment fields, namely - keyword:, - recommended: and - 
recommendedover:, allow Swift users to cooperate with code completion engine to 
deliver more effective code completion results. The - keyword: field specifies 
concepts that are not fully manifested in declaration names. - recommended: 
indicates other declarations are preferred to the one decorated; to the 
contrary, - recommendedover: indicates the decorated declaration is preferred 
to those declarations whose names are specified.

-- E


> On May 16, 2016, at 1:14 PM, Brandon Knope  wrote:
> 
> I have never seen anyone use this. Why? Because it is relatively unknown and 
> not very “pretty” in my opinion. In the ideal world, everyone would have 
> perfectly formatted and up to date comment, but I am not convinced this is 
> usually the case.
> 
> It’s good for IDE documenting, but:
> • Online tutorials do NOT use this in code samples, keeping it from being 
> widely known (and because it looks ugly next to their sample and makes it 
> look more verbose)
> • It really does not look nice with the language. It seems like IDE magic
> • What about people writing in a text editor or not in Xcode? If they do not 
> get a benefit out of // MARK: or /// - Keyword: why would they use it?
> 
> And a quick read of Matthew’s proposal tells me that it may be beneficial to 
> be able to refer to the name of an extension in the future. I am still 
> reading through his proposal but that’s what I took from it with a quick look.
> 
> 
> Brandon
> 
>> On May 16, 2016, at 3:08 PM, Erica Sadun  wrote:
>> 
>> Or better yet, the 'Keyword" token offers searchable content that can relate 
>> one extension to the other.
>> 
>> /// - Keyword: Lifecycle extension
>> 
>> -- Erica
>> 
>> 
>>> On May 16, 2016, at 11:33 AM, Michael Peternell via swift-evolution 
>>>  wrote:
>>> 
>>> Why not just use a (documentation) comment?
>>> 
>>> /// The Lifecycle extension:
>>> extension ViewController {
>>> ...
>>> 
>>> -Michael
>>> 
 Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution 
 :
 
 I like to separate methods into their own logical extensions so similar 
 methods are grouped together. I do this mostly with Cocoa Touch where I 
 like all view life cycle methods to be in the same extension:
 
 extension ViewController {
  override func viewDidLoad() {
  }
 
  override func viewWillAppear(animated: Bool) {
  }
 
  override func viewDidDisappear(animated: Bool) {
  }
 }
 
 You can document this somewhat by adding a MARK comment:
 
 // MARK: Lifecylce
 extension ViewController {
  override func viewDidLoad() {
  }
 
  override func viewWillAppear(animated: Bool) {
  }
 
  override func viewDidDisappear(animated: Bool) {
  }
 }
 
 What if we made this more self-documenting by elevating this to a language 
 feature?
 
 extension ViewController named Lifecycle {
  override func viewDidLoad() {
  }
 
  override func viewWillAppear(animated: Bool) {
  }
 
  override func viewDidDisappear(animated: Bool) {
  }
 }
 
 Other ways:
 extension named Lifecycle ViewController { }
 extension named “View Lifecycle" ViewController { }
 extension ViewController named “Multi word description” { }
 
 
 For now, this is purely a documenting feature (i.e. Can’t refer to the 
 extension name dynamically or statically in actual code). I think it plays 
 much more naturally with Swift than requiring this to be in the comments 
 and would work across all IDEs and make it easier for people to find a 
 specific extension as well as making their code more self documenting.
 
 Any thoughts?
 
 Thanks,
 Brandon
 
 
 
 ___
 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

Re: [swift-evolution] Idea: Named extensions

[Brandon Knope via swift-evolution]

I have never seen anyone use this. Why? Because it is relatively unknown and 
not very “pretty” in my opinion. In the ideal world, everyone would have 
perfectly formatted and up to date comment, but I am not convinced this is 
usually the case.

It’s good for IDE documenting, but:
• Online tutorials do NOT use this in code samples, keeping it from being 
widely known (and because it looks ugly next to their sample and makes it look 
more verbose)
• It really does not look nice with the language. It seems like IDE magic
• What about people writing in a text editor or not in Xcode? If they do not 
get a benefit out of // MARK: or /// - Keyword: why would they use it?

And a quick read of Matthew’s proposal tells me that it may be beneficial to be 
able to refer to the name of an extension in the future. I am still reading 
through his proposal but that’s what I took from it with a quick look.


Brandon

> On May 16, 2016, at 3:08 PM, Erica Sadun  wrote:
> 
> Or better yet, the 'Keyword" token offers searchable content that can relate 
> one extension to the other.
> 
> /// - Keyword: Lifecycle extension
> 
> -- Erica
> 
> 
>> On May 16, 2016, at 11:33 AM, Michael Peternell via swift-evolution 
>>  wrote:
>> 
>> Why not just use a (documentation) comment?
>> 
>> /// The Lifecycle extension:
>> extension ViewController {
>> ...
>> 
>> -Michael
>> 
>>> Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution 
>>> :
>>> 
>>> I like to separate methods into their own logical extensions so similar 
>>> methods are grouped together. I do this mostly with Cocoa Touch where I 
>>> like all view life cycle methods to be in the same extension:
>>> 
>>> extension ViewController {
>>>   override func viewDidLoad() {
>>>   }
>>> 
>>>   override func viewWillAppear(animated: Bool) {
>>>   }
>>> 
>>>   override func viewDidDisappear(animated: Bool) {
>>>   }
>>> }
>>> 
>>> You can document this somewhat by adding a MARK comment:
>>> 
>>> // MARK: Lifecylce
>>> extension ViewController {
>>>   override func viewDidLoad() {
>>>   }
>>> 
>>>   override func viewWillAppear(animated: Bool) {
>>>   }
>>> 
>>>   override func viewDidDisappear(animated: Bool) {
>>>   }
>>> }
>>> 
>>> What if we made this more self-documenting by elevating this to a language 
>>> feature?
>>> 
>>> extension ViewController named Lifecycle {
>>>   override func viewDidLoad() {
>>>   }
>>> 
>>>   override func viewWillAppear(animated: Bool) {
>>>   }
>>> 
>>>   override func viewDidDisappear(animated: Bool) {
>>>   }
>>> }
>>> 
>>> Other ways:
>>> extension named Lifecycle ViewController { }
>>> extension named “View Lifecycle" ViewController { }
>>> extension ViewController named “Multi word description” { }
>>> 
>>> 
>>> For now, this is purely a documenting feature (i.e. Can’t refer to the 
>>> extension name dynamically or statically in actual code). I think it plays 
>>> much more naturally with Swift than requiring this to be in the comments 
>>> and would work across all IDEs and make it easier for people to find a 
>>> specific extension as well as making their code more self documenting.
>>> 
>>> Any thoughts?
>>> 
>>> Thanks,
>>> Brandon
>>> 
>>> 
>>> 
>>> ___
>>> 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

Re: [swift-evolution] Idea: Named extensions

[Erica Sadun via swift-evolution]

Or better yet, the 'Keyword" token offers searchable content that can relate 
one extension to the other.

/// - Keyword: Lifecycle extension

-- Erica


> On May 16, 2016, at 11:33 AM, Michael Peternell via swift-evolution 
>  wrote:
> 
> Why not just use a (documentation) comment?
> 
> /// The Lifecycle extension:
> extension ViewController {
> ...
> 
> -Michael
> 
>> Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution 
>> :
>> 
>> I like to separate methods into their own logical extensions so similar 
>> methods are grouped together. I do this mostly with Cocoa Touch where I like 
>> all view life cycle methods to be in the same extension:
>> 
>> extension ViewController {
>>override func viewDidLoad() {
>>}
>> 
>>override func viewWillAppear(animated: Bool) {
>>}
>> 
>>override func viewDidDisappear(animated: Bool) {
>>}
>> }
>> 
>> You can document this somewhat by adding a MARK comment:
>> 
>> // MARK: Lifecylce
>> extension ViewController {
>>override func viewDidLoad() {
>>}
>> 
>>override func viewWillAppear(animated: Bool) {
>>}
>> 
>>override func viewDidDisappear(animated: Bool) {
>>}
>> }
>> 
>> What if we made this more self-documenting by elevating this to a language 
>> feature?
>> 
>> extension ViewController named Lifecycle {
>>override func viewDidLoad() {
>>}
>> 
>>override func viewWillAppear(animated: Bool) {
>>}
>> 
>>override func viewDidDisappear(animated: Bool) {
>>}
>> }
>> 
>> Other ways:
>> extension named Lifecycle ViewController { }
>> extension named “View Lifecycle" ViewController { }
>> extension ViewController named “Multi word description” { }
>> 
>> 
>> For now, this is purely a documenting feature (i.e. Can’t refer to the 
>> extension name dynamically or statically in actual code). I think it plays 
>> much more naturally with Swift than requiring this to be in the comments and 
>> would work across all IDEs and make it easier for people to find a specific 
>> extension as well as making their code more self documenting.
>> 
>> Any thoughts?
>> 
>> Thanks,
>> Brandon
>> 
>> 
>> 
>> ___
>> 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

Re: [swift-evolution] Idea: Named extensions

[Matthew Johnson via swift-evolution]

> On May 16, 2016, at 1:59 PM, Brandon Knope  wrote:
> 
> Do you have a link to your proposal?

The part relevant to this thread is in the section “Interactions with other 
features”

https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/-partial-initializers.md

> 
> Thanks,
> Brandon
> 
>> On May 16, 2016, at 2:58 PM, Matthew Johnson > > wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On May 16, 2016, at 12:33 PM, Michael Peternell via swift-evolution 
>>> > wrote:
>>> 
>>> Why not just use a (documentation) comment?
>>> 
>>> /// The Lifecycle extension:
>>> extension ViewController {
>> 
>> There have been discussions about possibly allowing extensions to have 
>> stored properties in the future.  If that comes to pass it may well be 
>> useful for extensions to have a name that can be used to refer to the 
>> extension during initialization.  I discussed possible syntax for that in my 
>> draft proposal for partial initializers (which I tabled for Swift 3, but may 
>> revive in the future).
>> 
>> 
>>> ...
>>> 
>>> -Michael
>>> 
 Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution 
 >:
 
 I like to separate methods into their own logical extensions so similar 
 methods are grouped together. I do this mostly with Cocoa Touch where I 
 like all view life cycle methods to be in the same extension:
 
 extension ViewController {
   override func viewDidLoad() {
   }
 
   override func viewWillAppear(animated: Bool) {
   }
 
   override func viewDidDisappear(animated: Bool) {
   }
 }
 
 You can document this somewhat by adding a MARK comment:
 
 // MARK: Lifecylce
 extension ViewController {
   override func viewDidLoad() {
   }
 
   override func viewWillAppear(animated: Bool) {
   }
 
   override func viewDidDisappear(animated: Bool) {
   }
 }
 
 What if we made this more self-documenting by elevating this to a language 
 feature?
 
 extension ViewController named Lifecycle {
   override func viewDidLoad() {
   }
 
   override func viewWillAppear(animated: Bool) {
   }
 
   override func viewDidDisappear(animated: Bool) {
   }
 }
 
 Other ways:
 extension named Lifecycle ViewController { }
 extension named “View Lifecycle" ViewController { }
 extension ViewController named “Multi word description” { }
 
 
 For now, this is purely a documenting feature (i.e. Can’t refer to the 
 extension name dynamically or statically in actual code). I think it plays 
 much more naturally with Swift than requiring this to be in the comments 
 and would work across all IDEs and make it easier for people to find a 
 specific extension as well as making their code more self documenting.
 
 Any thoughts?
 
 Thanks,
 Brandon
 
 
 
 ___
 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

Re: [swift-evolution] Idea: Named extensions

[Brandon Knope via swift-evolution]

Do you have a link to your proposal?

Thanks,
Brandon

> On May 16, 2016, at 2:58 PM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On May 16, 2016, at 12:33 PM, Michael Peternell via swift-evolution 
>> > wrote:
>> 
>> Why not just use a (documentation) comment?
>> 
>> /// The Lifecycle extension:
>> extension ViewController {
> 
> There have been discussions about possibly allowing extensions to have stored 
> properties in the future.  If that comes to pass it may well be useful for 
> extensions to have a name that can be used to refer to the extension during 
> initialization.  I discussed possible syntax for that in my draft proposal 
> for partial initializers (which I tabled for Swift 3, but may revive in the 
> future).
> 
> 
>> ...
>> 
>> -Michael
>> 
>>> Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution 
>>> :
>>> 
>>> I like to separate methods into their own logical extensions so similar 
>>> methods are grouped together. I do this mostly with Cocoa Touch where I 
>>> like all view life cycle methods to be in the same extension:
>>> 
>>> extension ViewController {
>>>   override func viewDidLoad() {
>>>   }
>>> 
>>>   override func viewWillAppear(animated: Bool) {
>>>   }
>>> 
>>>   override func viewDidDisappear(animated: Bool) {
>>>   }
>>> }
>>> 
>>> You can document this somewhat by adding a MARK comment:
>>> 
>>> // MARK: Lifecylce
>>> extension ViewController {
>>>   override func viewDidLoad() {
>>>   }
>>> 
>>>   override func viewWillAppear(animated: Bool) {
>>>   }
>>> 
>>>   override func viewDidDisappear(animated: Bool) {
>>>   }
>>> }
>>> 
>>> What if we made this more self-documenting by elevating this to a language 
>>> feature?
>>> 
>>> extension ViewController named Lifecycle {
>>>   override func viewDidLoad() {
>>>   }
>>> 
>>>   override func viewWillAppear(animated: Bool) {
>>>   }
>>> 
>>>   override func viewDidDisappear(animated: Bool) {
>>>   }
>>> }
>>> 
>>> Other ways:
>>> extension named Lifecycle ViewController { }
>>> extension named “View Lifecycle" ViewController { }
>>> extension ViewController named “Multi word description” { }
>>> 
>>> 
>>> For now, this is purely a documenting feature (i.e. Can’t refer to the 
>>> extension name dynamically or statically in actual code). I think it plays 
>>> much more naturally with Swift than requiring this to be in the comments 
>>> and would work across all IDEs and make it easier for people to find a 
>>> specific extension as well as making their code more self documenting.
>>> 
>>> Any thoughts?
>>> 
>>> Thanks,
>>> Brandon
>>> 
>>> 
>>> 
>>> ___
>>> 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

Re: [swift-evolution] Idea: Named extensions

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 16, 2016, at 12:33 PM, Michael Peternell via swift-evolution 
>  wrote:
> 
> Why not just use a (documentation) comment?
> 
> /// The Lifecycle extension:
> extension ViewController {

There have been discussions about possibly allowing extensions to have stored 
properties in the future.  If that comes to pass it may well be useful for 
extensions to have a name that can be used to refer to the extension during 
initialization.  I discussed possible syntax for that in my draft proposal for 
partial initializers (which I tabled for Swift 3, but may revive in the future).


> ...
> 
> -Michael
> 
>> Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution 
>> :
>> 
>> I like to separate methods into their own logical extensions so similar 
>> methods are grouped together. I do this mostly with Cocoa Touch where I like 
>> all view life cycle methods to be in the same extension:
>> 
>> extension ViewController {
>>override func viewDidLoad() {
>>}
>> 
>>override func viewWillAppear(animated: Bool) {
>>}
>> 
>>override func viewDidDisappear(animated: Bool) {
>>}
>> }
>> 
>> You can document this somewhat by adding a MARK comment:
>> 
>> // MARK: Lifecylce
>> extension ViewController {
>>override func viewDidLoad() {
>>}
>> 
>>override func viewWillAppear(animated: Bool) {
>>}
>> 
>>override func viewDidDisappear(animated: Bool) {
>>}
>> }
>> 
>> What if we made this more self-documenting by elevating this to a language 
>> feature?
>> 
>> extension ViewController named Lifecycle {
>>override func viewDidLoad() {
>>}
>> 
>>override func viewWillAppear(animated: Bool) {
>>}
>> 
>>override func viewDidDisappear(animated: Bool) {
>>}
>> }
>> 
>> Other ways:
>> extension named Lifecycle ViewController { }
>> extension named “View Lifecycle" ViewController { }
>> extension ViewController named “Multi word description” { }
>> 
>> 
>> For now, this is purely a documenting feature (i.e. Can’t refer to the 
>> extension name dynamically or statically in actual code). I think it plays 
>> much more naturally with Swift than requiring this to be in the comments and 
>> would work across all IDEs and make it easier for people to find a specific 
>> extension as well as making their code more self documenting.
>> 
>> Any thoughts?
>> 
>> Thanks,
>> Brandon
>> 
>> 
>> 
>> ___
>> 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

Re: [swift-evolution] Winding down the Swift 3 release

[Ryan Lovelett via swift-evolution]

On Mon, May 16, 2016, at 11:18 AM, Chris Lattner via swift-evolution
wrote:
> Hi Everyone,
> 
> As we get deeper into the Swift 3 release cycle, we’re beginning to have
> a more precise understanding about what the release will shape up to be. 
> Ted posted details of the Swift 3 release process last week
> (https://swift.org/blog/swift-3-0-release-process/) and I just updated
> the main swift-evolution README.md file
> (https://github.com/apple/swift-evolution) with some updated details
> about the goals of Swift 3.

I noticed this comment on Hacker News:
https://news.ycombinator.com/item?id=11708052

The comment brought up a question about the "Portability" section
disappearing from the README. Until reading that comment I had not
noticed the removal of the goal. But upon examination I would like to
know what the implication of that removal is.

Would you mind expanding on the implications of that section
disappearing? Just an accidental omission? Is portability now considered
done/achieved? Or are the core team members throwing in the towel on
that goal? (Perhaps it is some variation on those themes or something
completely different)

> 
> This release is shaping up to be a really phenomenal release that will
> redefine the feel of Swift and make a major leap towards maturing the
> Swift language and development experience.  We have had a focus on
> getting to source stability, with the forward-looking goal of making
> Swift 4 as source compatible with Swift 3 as we can reasonably
> accomplish.  It tackled API naming head on (which is one of the hardest
> problems in computer science [1]), made major improvements to the
> consistency and feel of the language, and has several nice across the
> board additions.
> 
> That said, it is also clear at this point that some of the loftier goals
> that we started out with aren’t going to fit into the release - including
> some of the most important generics features needed in order to lock down
> the ABI of the standard library. As such, the generics and ABI stability
> goals will roll into a future release of Swift, where I expect them to be
> the *highest* priority features to get done.
> 
> I expect discussion and planning for Swift 3.x and Swift 4 to start
> sometime around August of this year.  Until then, it is very important
> that we as a community stay focused on the goals of Swift 3: I’d really
> prefer us all to resist the urge to discuss major blue sky features for
> future releases.  We would also like to put a significant amount of
> effort into bug fixing and quality refinements as well, which means that
> the core team will be proactively deferring evolution proposals to later
> releases that don’t align with the Swift 3 goals, especially those that
> are strictly additive.
> 
> Thank you for all of the amazing community that has developed on this
> list, it is great to work with you all!  Let us know if you have any
> questions,
> 
> -Chris
> 
> [1] It is well known that the two hard problems in Computer Science are
> naming, cache invalidation, and off-by-one errors.
> ___
> 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

Re: [swift-evolution] [Review] SE-0085: Package Manager Command Names

[Daniel Dunbar via swift-evolution]

Hello Swift community,

The Swift package manager core team met last week to discuss this proposal, and 
we ultimately *accepted* it relatively unchanged. I have amended the proposal 
to include more information on the alternatives discussed:
  
https://github.com/apple/swift-evolution/blob/master/proposals/0085-package-manager-command-name.md

We discussed at length the `spm` and `swiftpm` alternatives raised on this 
thread. In the end, we chose not to go that direction with the proposal for the 
reasons I included. We do recognized the desire for a shorter command, and view 
having an alias as something that can be added later if it proves to be the 
right thing to do.

Thanks!
 - Daniel

> On May 9, 2016, at 3:05 PM, Daniel Dunbar via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0085: Package Manager Command Names" begins now and runs 
> through May 12. The proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0085-package-manager-command-name.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> - Daniel
> Review Manager
> 
> 
> ___
> 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

Re: [swift-evolution] Winding down the Swift 3 release

[Tim Hawkins via swift-evolution]

At what point would you consider the Linux product to be viable for
production server side application development. Do you think that goal has
been achieved in swift 3.0. Or is it going to have to wait for the ABI lock
down.

I'm weighting the wisdom of possibly using Swift on linux for
microservices, we are comming from a modernPHP and OOP environment, and
many of the alternatives such as go and rust have higher impedance
mismatches than swift,  given the skills I have available in the
organisation.

I'm interested in cross platform app development down the line, but for
now, I'm only really interested in building out APIs with it.
On 17 May 2016 02:14, "Chris Lattner via swift-evolution" <
swift-evolution@swift.org> wrote:

> On May 16, 2016, at 10:38 AM, Goffredo Marocchi  wrote:
> > Quite sad we could not get into ABI stability for Swift 3... but are we
> talking Swift 3.1 or 4.0?
>
> We’ll start discussing post-3.0 releases in August.  Until Swift 3 is
> really wound down, it is almost impossible to make forward looking plans.
>
> -Chris
>
> >
> > Sent from my iPhone
> >
> >> On 16 May 2016, at 17:43, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>
> >>> On May 16, 2016, at 9:29 AM, David Sweeris 
> wrote:
> >>>
> >>>
>  On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
>  That said, it is also clear at this point that some of the loftier
> goals that we started out with aren’t going to fit into the release -
> including some of the most important generics features needed in order to
> lock down the ABI of the standard library. As such, the generics and ABI
> stability goals will roll into a future release of Swift, where I expect
> them to be the *highest* priority features to get done.
> >>>
> >>> Oh, good! I was getting worried about that. Are there any particular
> topics that we should drop or discuss?
> >>
> >> The highest priority to me is to get the “little syntactic stuff” done
> that we want to nail down because it affects source stability.  A recent
> thing that came up was @noescape -> @nonescaping and whether to make it the
> default, for example.
> >>
> >> As for dropping, it is pretty clear that we are out of time for
> large-scope additions.
> >>
> >> -Chris
> >> ___
> >> 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

Re: [swift-evolution] Idea: Named extensions

[Brandon Knope via swift-evolution]

Because to me this seems too indirect and not explicit enough.

I think doing it explicitly:
• Makes your intent much clearer
• Forces you to think about not throwing everything into one big extension 
(i.e. somewhat more binding than a comment that can easily be looked over)
• Shows that it’s a first class feature of the language, encouraging everyone 
to use it. Makes it easier to see in tutorials and code samples as it reads 
more natural than // MARK:
• Does not feel hacky with a comment (and comments are easy to forget to 
update, making them possibly outdated)
• Looks better than having to use comments (imo)

It is reminiscent of named categories in Objective-C where I found the names to 
be quite self documenting and clearer.

To me it just feels like a natural extension…onto extensions.

In the end, there is nothing with wrong using comments, but it feels a little 
more archaic to me. 

For a little contrived example:

In the swift guide, there is an example like this:

extension Double {
var km: Double { return self * 1_000.0 }
var m: Double { return self }
var cm: Double { return self / 100.0 }
var mm: Double { return self / 1_000.0 }
var ft: Double { return self / 3.28084 }
}

• It is clear what the intent is here: to provide methods to convert a double 
into other units
• Why not make this intent explicit? Otherwise it is too easy to add unrelated 
methods:

extension Double {
var km: Double { return self * 1_000.0 }
var m: Double { return self }
var cm: Double { return self / 100.0 }
var mm: Double { return self / 1_000.0 }
var ft: Double { return self / 3.28084 }

var squared: Double { return self * self } //This computed property 
is unlike the others, introducing some bloat to this extension
}



Something like this is more “explicit”

 named Unit Conversion extension Double {
var km: Double { return self * 1_000.0 }
var m: Double { return self }
var cm: Double { return self / 100.0 }
var mm: Double { return self / 1_000.0 }
var ft: Double { return self / 3.28084 }

  //var squared: Double { return self * self } It is not clear that 
this method does not fit with the others and should be moved
}

There is somewhat of a contract here where everything in this extension is a 
kind of conversion. Anyone could still add whatever they want to this extension 
because this is really just a form of documentation and it has no idea whether 
what you are adding fits with the name, but I find it to be a little more 
binding and requires the programmer to ask themselves if their addition fits 
with the rest of the extension.

The obvious question again is: Why not just use a comment to document it? My 
answer to this is: I don’t think most use comments to signify their intent of 
the extension. They either do not know it exists or do not find it worthwhile. 
I think making it explicit to the language gives people incentive to use it. It 
would be included in more code samples because it is a natural part of the 
extension and not “just another comment” to skim by, meaning more people would 
know it exists and use it more.

Also, no // MARK: Bar syntax needs to be remembered. MARK: is also less pretty 
and harder to type

More formatting options:

named Unit Conversion 
extension Double {
}

extension Double, named Unit Conversion { //avoids requiring “ "
} 

At the end of the day, how many developers know and remember to use // MARK:? I 
think this feature with code completion would promote much wider adoption.

Brandon

> On May 16, 2016, at 1:33 PM, Michael Peternell  
> wrote:
> 
> Why not just use a (documentation) comment?
> 
> /// The Lifecycle extension:
> extension ViewController {
> ...
> 
> -Michael
> 
>> Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution 
>> :
>> 
>> I like to separate methods into their own logical extensions so similar 
>> methods are grouped together. I do this mostly with Cocoa Touch where I like 
>> all view life cycle methods to be in the same extension:
>> 
>> extension ViewController {
>>override func viewDidLoad() {
>>}
>> 
>>override func viewWillAppear(animated: Bool) {
>>}
>> 
>>override func viewDidDisappear(animated: Bool) {
>>}
>> }
>> 
>> You can document this somewhat by adding a MARK comment:
>> 
>> // MARK: Lifecylce
>> extension ViewController {
>>override func viewDidLoad() {
>>}
>> 
>>override func viewWillAppear(animated: Bool) {
>>}
>> 
>>override func viewDidDisappear(animated: Bool) {
>>}
>> }
>> 
>> What if we made this more self-documenting by elevating this to a language 
>> feature?
>> 
>> extension ViewController named Lifecycle {
>>override func viewDidLoad() {
>>}
>> 
>>override func viewWillAppear(animated: Bool) {
>>}
>> 
>>override func viewDidDisappear(animated: Bool) {
>>}
>> }
>> 
>> Other ways:
>> extension named 

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Thorsten Seitz via swift-evolution]

> Am 16.05.2016 um 17:04 schrieb Karl via swift-evolution 
> :
> 
>> internal func _arrayOutOfPlaceReplace
>> 
>> (_ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount: Int)
>> where
>> C.Iterator.Element == B.Element,
>> B.Index == Int
>> {
>> 
>> Now only the relatively unimportant details—that the buffer and collection 
>> must have elements of the same type, and that the buffer must have integer 
>> indices—are at the end, whereas the basic conformances required to make any 
>> sense at all of the declaration are still inline.
> 
> You see, I’m of the complete opposite opinion - I don’t think those details 
> are “relatively unimportant”; I think they’re absolutely critical.
> 
> If you try and call it when your C.Iterator.Element is not equal to 
> B.Element, the function does not exist. You’re talking about some other 
> function in that case, not this one.
> 
> Same goes if B.Index is not an Int. If that was an unimportant detail, they 
> would have given ‘bounds’ the type Range and not specified any 
> constraints at all. The function requires the index be an Int - maybe it’s 
> doing some mathematical operations which wouldn’t make sense for a more 
> complex index type, such as DictionaryIndex.
> 
> Basically that is it - the ‘where’ clause is a vital part of the function 
> declaration; it defines the specification under which the function exists at 
> all (along with the function name, arguments and return type). If you don’t 
> match every single part of that specification, the type checker won’t match 
> your call to this function - if you don’t meet the constraints, you’re not 
> talking about this function; imagine you have several overloaded function 
> declarations which differ only by ‘where’ condition:
> 
> func insert(contentsOf:T) where T:RandomAccessCollection, T.Element == 
> Element
> func insert(contentsOf:T) where T:Collection, T.Element == Element
> func insert(contentsOf:T) where T:Sequence, T.Element == Element
> … etc
> 
> the ‘where’ clause isn’t incidental here - it’s the only disambiguating 
> feature between these declarations. I think it’s critical information and 
> shouldn’t be stuffed at the end because you think it’s not important; it is 
> important. If it hinders initial readability of the declaration so much, you 
> can wrap it behind a typealias:
> 
> func insert>(contentsOf: T)
> func insert>(contentsOf: T)
> func insert>(contentsOf: T)
> … etc

Either you have the constraints first and the parameter list last or the other 
way around. Fact is that *both* decide whether it is the function you need.
So just their order cannot help with that.
I would still argue that the proposed version is more readable: just look at 
your example above where the first part up to the where is identical at one 
glance, so that the disambiguating part stands out whereas your other example 
looks much more unstructured because of the different lengths of the generic 
type list which makes the congruence of the parameter lists difficult to see 
because they do not align anymore.

> 
> I think that’s much easier to follow, and attempts to reduces the length and 
> verbosity of the where clauses (i.e. like the fact that Collection’s 
> associated type referring to its element is called ‘Element’; ‘CollectionOf’ 
> encodes an equivalent constraint in less characters). This proposal just 
> feels kind of lazy - we’ll just tack them on the end so we can ignore them a 
> bit more easily, even though they’re still going to be monstrously long and 
> difficult-to-read.

The typealias idea can be combined with the where clause at the end:

func insert(contentsOf:T) where T:RandomAccessCollectionOf
func insert(contentsOf:T) where T:CollectionOf
func insert(contentsOf:T) where T:SequenceOf

Much easier to discern (at least IMO) because everything is aligned.

> 
> Are there any other languages that do this? Or anything even similar? It 
> seems to me that the context-switching is something that human beings in 
> general are not going to find very legible; like if you insert too many 
> commas in a sentence.

Yes, Ceylon places all constraints (it only knows inheritance constraints) at 
the end:

shared Value sum({Value+} values) 
given Value satisfies Summable { ... }
shared Item>[] zip({Key*} keys, {Item*} items)
given Key satisfies Object
given Item satisfies Object { ... }

It does the same for type definitions:
shared class Singleton(Element element)
extends Object()
satisfies [Element+]
given Element satisfies Object { ... }

-Thorsten

> 
>> On 15 May 2016, at 16:05, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> There we are. I read the declaration of the function from beginning to end
>>> and gradually formed a rough understanding of it without needing to change
>>> my expectations halfway through. I still have doubts about 'insertCount',
>>> but I 

Re: [swift-evolution] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

On May 16, 2016, at 10:38 AM, Goffredo Marocchi  wrote:
> Quite sad we could not get into ABI stability for Swift 3... but are we 
> talking Swift 3.1 or 4.0?

We’ll start discussing post-3.0 releases in August.  Until Swift 3 is really 
wound down, it is almost impossible to make forward looking plans.

-Chris

> 
> Sent from my iPhone
> 
>> On 16 May 2016, at 17:43, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On May 16, 2016, at 9:29 AM, David Sweeris  wrote:
>>> 
>>> 
 On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution 
  wrote:
 
 That said, it is also clear at this point that some of the loftier goals 
 that we started out with aren’t going to fit into the release - including 
 some of the most important generics features needed in order to lock down 
 the ABI of the standard library. As such, the generics and ABI stability 
 goals will roll into a future release of Swift, where I expect them to be 
 the *highest* priority features to get done.
>>> 
>>> Oh, good! I was getting worried about that. Are there any particular topics 
>>> that we should drop or discuss?
>> 
>> The highest priority to me is to get the “little syntactic stuff” done that 
>> we want to nail down because it affects source stability.  A recent thing 
>> that came up was @noescape -> @nonescaping and whether to make it the 
>> default, for example.
>> 
>> As for dropping, it is pretty clear that we are out of time for large-scope 
>> additions.
>> 
>> -Chris
>> ___
>> 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

Re: [swift-evolution] Winding down the Swift 3 release

[Goffredo Marocchi via swift-evolution]

Quite sad we could not get into ABI stability for Swift 3... but are we talking 
Swift 3.1 or 4.0?

Sent from my iPhone

> On 16 May 2016, at 17:43, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On May 16, 2016, at 9:29 AM, David Sweeris  wrote:
>> 
>> 
>>> On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> That said, it is also clear at this point that some of the loftier goals 
>>> that we started out with aren’t going to fit into the release - including 
>>> some of the most important generics features needed in order to lock down 
>>> the ABI of the standard library. As such, the generics and ABI stability 
>>> goals will roll into a future release of Swift, where I expect them to be 
>>> the *highest* priority features to get done.
>> 
>> Oh, good! I was getting worried about that. Are there any particular topics 
>> that we should drop or discuss?
> 
> The highest priority to me is to get the “little syntactic stuff” done that 
> we want to nail down because it affects source stability.  A recent thing 
> that came up was @noescape -> @nonescaping and whether to make it the 
> default, for example.
> 
> As for dropping, it is pretty clear that we are out of time for large-scope 
> additions.
> 
> -Chris
> ___
> 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

Re: [swift-evolution] Idea: Named extensions

[Michael Peternell via swift-evolution]

Why not just use a (documentation) comment?

/// The Lifecycle extension:
extension ViewController {
...

-Michael

> Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution 
> :
> 
> I like to separate methods into their own logical extensions so similar 
> methods are grouped together. I do this mostly with Cocoa Touch where I like 
> all view life cycle methods to be in the same extension:
> 
> extension ViewController {
> override func viewDidLoad() {
> }
> 
> override func viewWillAppear(animated: Bool) {
> }
> 
> override func viewDidDisappear(animated: Bool) {
> }
> }
> 
> You can document this somewhat by adding a MARK comment:
> 
> // MARK: Lifecylce
> extension ViewController {
> override func viewDidLoad() {
> }
> 
> override func viewWillAppear(animated: Bool) {
> }
> 
> override func viewDidDisappear(animated: Bool) {
> }
> }
> 
> What if we made this more self-documenting by elevating this to a language 
> feature?
> 
> extension ViewController named Lifecycle {
> override func viewDidLoad() {
> }
> 
> override func viewWillAppear(animated: Bool) {
> }
> 
> override func viewDidDisappear(animated: Bool) {
> }
> }
> 
> Other ways:
> extension named Lifecycle ViewController { }
> extension named “View Lifecycle" ViewController { }
> extension ViewController named “Multi word description” { }
> 
> 
> For now, this is purely a documenting feature (i.e. Can’t refer to the 
> extension name dynamically or statically in actual code). I think it plays 
> much more naturally with Swift than requiring this to be in the comments and 
> would work across all IDEs and make it easier for people to find a specific 
> extension as well as making their code more self documenting.
> 
> Any thoughts?
> 
> Thanks,
> Brandon
> 
> 
> 
> ___
> 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

Re: [swift-evolution] Could enums have their rawValue type inferred?

[Eric Miller via swift-evolution]

> automatically cast rawValue when assigning an enum value to
a variable or argument of the type of the enum's raw value

That's exactly what I'm thinking, Leonardo. I was a little bit trying to
avoid specifics because I don't understand the differences between
autocasting and inference.

There's a small miscommunication though--This api works great since it
accepts the enum type, rather than the underlying value type. Signature:

static func fadeIn(view: UIView?, withSpeed: Animate.transitionSpeed =
Animate.transitionSpeed.fast)

The goal was to provide my users with a good default and an easy set of
configurable options at the call site like `.fast`, `.normal`, `.slow`.

(unrelated: +1 on inferring type of function params with default values, I
hit this all the time)

Calling:

Animate.fadeIn(myView, withSpeed: .slow)

Works great.

This library of methods is a facade for CABasicAnimation or UIView
animations which take an NSTimeInterval, and that's where the "autocasting"
would come into play.



--

Message: 31
Date: Fri, 13 May 2016 16:58:06 -0300
From: Leonardo Pessoa 
To: Swift-evolution 
Subject: Re: [swift-evolution] Could enums have their rawValue type
inferred?
Message-ID:

Content-Type: text/plain; charset="utf-8"

Eric, I think I understood your proposal. If I may explain in other words
it would be "to automatically cast rawValue when assigning an enum value to
a variable or argument of the type of the enum's raw value", am I right? I
think this would imply a little more inference and type checking rules from
the compiler and maybe even take a little longer to fully compile code. I'm
not sure it's feasible but from your examples, I can see how it enhances
readability of the code, so I'm +1 for it. My only concern is that you
would still need to fully declare the enum's name where the value of the
enum is used. Taking from your own example

Animate.fadeIn(view, withSpeed: .fast)

couldn't be called that way if withSpeed expects and NSTimeInterval because
the compiler won't know whether you're refering to transitionSpeed or to
ambientAnimationSpeed. You would still have to call it like

Animate.fadeIn(view, withSpeed: transitionSpeed.fast)

even if you had only one possible enum value over all declared enums
because that would still force the compiler to search for each value over
all known enums to define where the value you're using comes from and make
sure there are no two enums with the same value.

Aside from that, I good with the idea.



On 13 May 2016 at 15:09, Eric Miller via swift-evolution <
swift-evolution@swift.org> wrote:

> This might open a larger can of worms than I imagine, but what do you
> folks think about using the `rawValue` of an enum when that rawValue is a
> fit for the expected type?
>
> Use case.
>
> I'm making an animation facade, and it has some speed presets:
>
> class Animate {
>   enum transitionSpeed: NSTimeInterval {
> case fast = 0.15
> case slow = 0.5
>   }
>   enum ambientAnimationSpeed: NSTimeInterval {
> case fast = 1.0
> case slow = 5.0
>   }
>   ...
> }
>
> I did them with static variables at first but that made the call site
> verbose. Compare:
>
> Animate.fadeIn(view, withSpeed: Animate.cfg.transitionFast)
> Animate.fadeIn(view, withSpeed: .fast)
>
> So, I like the enum approach better, but my library code has to use
> `rawValue` to do anything with the actual value, of course:
>
> static func fadeIn(view: UIView?, withSpeed duration:transitionSpeed =
> .fast) {
>   ...
>   UIView.animateWithDuration(duration.rawValue, animations: { })
> }
>
> It's not a serious issue, but the code is more clear and beautiful if it
> has just myIntent, rather than myIntent.rawValue.
>
> I've hit this issue when modeling other things, such as:
>
> * server fault codes
> * HTTP status codes
> * Currency codes
> * Days of the week
>
> Would it be appropriate to "autocast" to the rawValue of the enum when the
> rawValue's Type matches the type expectation of the API? Or would this
> introduce a bunch of type system uncertainty?
>
> Maybe this could be implemented as a protocol? It feels almost like the
> convenience of `CustomStringConvertible`'s `description` property.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] New mechanism to combine Types with/or Protocols

[Adrian Zubarev via swift-evolution]

I open a new thread just for clarity. This proposal was started two weeks ago 
in a discussion thread where I talked to the community and refined the proposal 
over a few past days. The overall response was positive to this proposal.

Original thread: [Pitch] merge types and protocols back together with 
type

This is my first proposal where I'll submit a pull request. Furthermore my 
English isn’t that great so please bear with me. If you spot any typos or other 
mistakes I’d be happy to look into your feedback. Feel free to send me such 
feedback in private.

Just for clarification: this proposal does not try to create type intersection 
in Swift, so please don’t ask me to change this. `Type intersection` is totally 
a different story and can have its own thread and proposal. ;)

Here is the formatted version of my proposal: 
https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/-mechanism-to-combine-types-and-protocols.md

I hope to see your final feedback before I submit the proposal to the evolution 
repository.

-- 
Adrian Zubarev
Sent with Airmail
New mechanism to combine Types with/or Protocols

Proposal: SE-
Author(s): Adrian Zubarev
Status: Awaiting review
Review manager: TBD
Introduction

The current protocol<> mechanism defines the Any protocol to which all types 
implicitly conform. It also can combine distinct protocols to a new Protocol, 
whereas combinging SubProtocol with its BaseProtocol will be inferred as 
SubProtocol (the order withhin the angle brackets doesn’t matter). I propose to 
replace the current protocol<> mechanism with a new more powerful mechanism 
called All<>, which will allow combining Types with independent Protocols and 
enforce all constraints.

Swift-evolution thread: [Pitch] Merge Types and Protocols back together with 
type

Motivation

The motivation for this proposal comes from solving the missing Type issue 
(rdar://20990743) and combining the idea mentioned in the generics manifesto 
for Swift 3 in section Renaming protocol<...> to Any<...>.

The proposed mechanism will allow us to create a new Type from extendable 
distinct types - there are still some restrinctions you can read about below.

Proposed solution

First step to implement this proposal would need to rename protocol<> to All<> 
and configure the migration process to update code that used old style 
protocol<>.

Next the All<> mechanism would be extended to allow nesting and at most one 
extendable value or reference type. When all types within angle brackets are 
indepented/distinct to each other a new Type will be formed by All. 
This new Type can be used to store instances that conform to all constrains 
defined by All<> without any generic context (see Detailed design for more 
information).

Here only some subtype of UIView (dynamic type) conforms to SomeProtocol, but 
both types within angle brackets are distinct.

protocol SomeProtocol {}
extension SomeProtocol {
func foo() { print("fo") }
}

// we'll be able to store the new type without generics
class A {
var view: All
init(view: All) {
self.view = view
}
 
// `dynamicType` of the `view` might be `UIButton` for example
// but we still be able to acces SomeProtocol which only UIButton conforms 
to
func doSomeWork() {
self.view.removeFromSuperview() // just for a simple example
self.view.foo() // prints "fo"
}
}

extension UIButton: SomeProtocol {}

let button: SomeProtocol = UIButton() // split types for the example

if let mergedValue = button as? All {
let a = A(view: mergedValue)
a.doSomeWork()
}
Detailed design

Rules for All<>:

Empty All<> will be used as typealias Any = All<>. No constraints means it can 
accept any type or simply that all types implicitly conform to empty All<>. 
This is the logical replacement for typealias Any = protocol<>.

The order of Types within angle brackets doesn’t matter: All == All. (The compiler already reorders the types by its own will from protocol to protocol.)

All<> can be composed from protocols and by the mention of this rule fully 
replace protocol<...>

All equals to old protocol
All equals to old protocol or simply inferred as ProtocolX
All<> can contain at most one extendable value or reference type plus none or n 
protocols.

All or All
All or All
This rule will disallow All<> to contain unnecessary inheritance type branches 
from subtypeable types.
Furthermore will this rule ban confusion when using All in a generic 
context.
Subtypeable Type from within angle brackets of All<> can be seen as the base 
type of the dynamic type.

Nesting All<> is allowed under special rules:

A: All<> can contain B: All<> if B is composed from protocols:
e.g. All

Re: [swift-evolution] Union instead of Optional

[Thorsten Seitz via swift-evolution]

> Am 16.05.2016 um 17:29 schrieb Michael Peternell via swift-evolution 
> :
> 
> 
>> Am 16.05.2016 um 12:07 schrieb Austin Zheng via swift-evolution 
>> :
>> 
>> Precisely. To me unions are to enums with associated type the same way 
>> tuples are to structs. One is named, has well-defined semantics, can conform 
>> to protocols, can have complex internal structure, can have methods, etc. 
>> The other is ad-hoc and lightweight, easy to define at the site of use, best 
>> suited for simple purposes, has special syntax to support it. 
>> 
>> Even if we can extend tuples in the future, though, I wouldn't want structs 
>> to go away. When exceeding some level of complexity structs are just more 
>> explicit than tuples, and therefore easier to understand.
>> 
>> Finally, please note that Ceylon is a pervasively object-oriented language 
>> with a single root superclass. Neither of those is true for Swift, which 
>> chooses to solve a lot of problems in a different (and I would argue, 
>> superior) way. So solutions that might work well in Ceylon might not be 
>> suited for Swift, at least not without modification, and vice versa. The 
>> core team could certainly have chosen to model Swift's type system after 
>> that of e.g. Scala, but they chose not to, and I think they did so for good 
>> reason.
> 
> Swift has a root class, it is called SwiftObject and it's visible from 
> Objective-C ;) Just thinking about it.. it makes sense: the whole 
> reference-counting-stuff has to live somewhere in the object, and there has 
> to be some kind of isa-pointer to allow for subclassing (and Objective-C 
> interoperability). So there is some common behavior regarding all classes 
> defined from Swift (they all implement retain, release, autorelease, 
> isEqual:, class, respondsToSelector:, the whole NSObject-protocol...) => what 
> I want to express: Java has a root-class, C++ has no root class - that's 
> uncontested; but Swift is somewhere in-between IMHO.
> 
> And for enums and unions.. I think they are different. enums are "sum-types" 
> and unions are... well... "union-types", when you think of data types as 
> sets. E.g. if A, B are data types (sets), then an enum that can be either 
> anA(A) or aB(B) can be thought of as the set A+B (and if A \intersect B 
> \not\eq \emptyset, you can think of this as (0,A)\union (1,B) ). A union B is 
> not the same. In C, the unions are not even safe, because they are not 
> discriminated in any way. In Swift they make an isomorphic set if A and B are 
> disjoint. If A=String and B=Int, A `enum` B is isomorphic to A `union` B 
> (sorry for abusing Haskell syntax :-/ ). But if A=Iterable and 
> B=Array, they are not the same, because now A is a superset of B. So 
> A `enum` B is a strict superset of A `union` B (== A). I can already imagine 
> weird bugs coming to the surface from this distinction, all of which can be 
> solved by disallowing union types altogether.

Ceylon’s type system handles these things nicely. Iterable | 
Array would reduce to Iterable, for example, and when switching 
over union types the type checker knows when types are not disjoint 
(disallowing the switch) or whether the switch is exhaustive.

For more details, see http://ceylon-lang.org/documentation/1.2/tour/types/

> 
> Therefore I think that unions are not worth the trouble at all. And they are 
> even possible right now: Instead of writing
> 
>union MyUnion { Int, String }
>// or typealias MyUnion = (Int | String) // ?
> 
> you'd have to write
> 
>protocol MyUnion {}
>extension Int: MyUnion {}
>extension String: MyUnion {}
> 
> The two definitions are basically equivalent, and the second is already valid 
> Swift.

Alas, that is only possible for explicit named unions but the power of type 
unions lies in their „ad hoc“-ness, e.g. in generic unions like

func union(a: Set, b: Set) -> Set { … }  // Note: all 
examples in hypothetically extended Swift syntax instead of Ceylon syntax

extension Dictionary {
func getOrDefault(default: Default) -> Value | Default // in 
the general simple case Default == Value, which results in Value | Default == 
Value
}

Ceylon models the concept of empty and non-empty streams by defining

protocol Iterable {
associatedtype Element
associatedtype Absent : Null = Null // Null is the type containing 
a single value null (= nil in Swift); Ceylon’s optionals are just type unions 
T? == T | Null

var first: Absent | Element { get }
var rest: Iterable where Iterable.Element == Element, Iterable.Absent 
== Null

// Produces a non-empty stream with a given initial element, followed 
by the elements of this stream, in the order in which they occur in this stream.
func follow(head: Other) -> Iterable where Iterable.Element == Element 
| Other, Iterable.Absent = Nothing
…
}

This means that
Iterable // with 

Re: [swift-evolution] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

> On May 16, 2016, at 9:29 AM, David Sweeris  wrote:
> 
> 
>> On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> That said, it is also clear at this point that some of the loftier goals 
>> that we started out with aren’t going to fit into the release - including 
>> some of the most important generics features needed in order to lock down 
>> the ABI of the standard library. As such, the generics and ABI stability 
>> goals will roll into a future release of Swift, where I expect them to be 
>> the *highest* priority features to get done.
> 
> Oh, good! I was getting worried about that. Are there any particular topics 
> that we should drop or discuss?

The highest priority to me is to get the “little syntactic stuff” done that we 
want to nail down because it affects source stability.  A recent thing that 
came up was @noescape -> @nonescaping and whether to make it the default, for 
example.

As for dropping, it is pretty clear that we are out of time for large-scope 
additions.

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Winding down the Swift 3 release

[David Sweeris via swift-evolution]

> On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> That said, it is also clear at this point that some of the loftier goals that 
> we started out with aren’t going to fit into the release - including some of 
> the most important generics features needed in order to lock down the ABI of 
> the standard library. As such, the generics and ABI stability goals will roll 
> into a future release of Swift, where I expect them to be the *highest* 
> priority features to get done.

Oh, good! I was getting worried about that. Are there any particular topics 
that we should drop or discuss?

- Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [META] Using escapes in Swift Evolution Proposal discussion links

[Erica Sadun via swift-evolution]

The standard Swift Evolution proposal template 
 
includes the following introduction section:

## Introduction
A short description of what the feature is. Try to keep it to a
single-paragraph "elevator pitch" so the reader understands what
problem this proposal is addressing.  

Swift-evolution thread: [Discussion thread topic for that 
proposal](https://lists.swift.org/pipermail/swift-evolution)


Swift Evolution email subjects commonly use square brackets in the subject 
line. This email does just that: "[META] Swift Evolution Proposals and 
Discussion Links". To create a valid markdown link, you must escape the square 
brackets. The following markup is malformed:
Swift-evolution thread: [[META] Swift Evolution Proposals and Discussion 
Links](gmane or pipermail url)
Add backslashes before square brackets within the topic:
Swift-evolution thread: [\[META\] Swift Evolution Proposals and Discussion 
Links](gmane or pipermail url)
Escaping enables Github to distinguish the bracket-deliniated text from the 
parenthesized URL.

Best regards,

-- E___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Idea: Named extensions

[Brandon Knope via swift-evolution]

I like to separate methods into their own logical extensions so similar methods 
are grouped together. I do this mostly with Cocoa Touch where I like all view 
life cycle methods to be in the same extension:

extension ViewController {
override func viewDidLoad() {
}

override func viewWillAppear(animated: Bool) {
}

override func viewDidDisappear(animated: Bool) {
}
}

You can document this somewhat by adding a MARK comment:

// MARK: Lifecylce
extension ViewController {
override func viewDidLoad() {
}

override func viewWillAppear(animated: Bool) {
}

override func viewDidDisappear(animated: Bool) {
}
}

What if we made this more self-documenting by elevating this to a language 
feature?

extension ViewController named Lifecycle {
override func viewDidLoad() {
}

override func viewWillAppear(animated: Bool) {
}

override func viewDidDisappear(animated: Bool) {
}
}

Other ways:
extension named Lifecycle ViewController { }
extension named “View Lifecycle" ViewController { }
extension ViewController named “Multi word description” { }


For now, this is purely a documenting feature (i.e. Can’t refer to the 
extension name dynamically or statically in actual code). I think it plays much 
more naturally with Swift than requiring this to be in the comments and would 
work across all IDEs and make it easier for people to find a specific extension 
as well as making their code more self documenting.

Any thoughts?

Thanks,
Brandon



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson via swift-evolution]

> On May 16, 2016, at 1:38 AM, Tyler Fleming Cloutier via swift-evolution 
>  wrote:
> 
>> 
>> On May 15, 2016, at 11:17 PM, Tyler Fleming Cloutier via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> on Mon May 09 2016, Matthew Johnson >> > wrote:
>>> 
> On May 8, 2016, at 1:51 AM, Dave Abrahams  > wrote:
> 
> 
> on Sat May 07 2016, Andrew Trick  > wrote:
> 
 
>>   On May 7, 2016, at 2:04 PM, Dave Abrahams > > wrote:
>> 
>>   2. Value types are not "pure" values if any part of the aggregate
>>   contains a
>>   reference whose type does not have value semantics. 
>> 
>>   Then Array is not a “pure” value (the buffer contained in an
>>   Array is a mutable reference type that on its own, definitely does
>>   *not* have value semantics). I don't think this is what you intend, and
>>   it indicates that you need to keep working on your definition.
>> 
>> It sounds like you’re changing the definition of value semantics to make 
>> it
>> impossible to define PureValue. 
> 
> Not on purpose.
> 
>> Does Array have value semantics then only if T also has value
>> semantics?
> 
> This is a great question; I had to rewrite my response four times.
> 
> In my world, an Array always has value semantics if you respect the
> boundaries of element values as defined by ==.  That means that if T is
> a mutable reference type, you're not looking through references, because
> == is equivalent to ===.
> 
> Therefore, for almost any interesting SomeConstraint that doesn't refine
> ValueSemantics, then
> 
> Array
> 
> only has value semantics if T has value semantics, since SomeConstraint
> presumably uses aspects of T other than reference identity.  
> 
>> The claim has been made that Array always has value semantics,
>> implying that the array value’s boundary ends at the boundary of it’s
>> element values.
> 
> Yes, an array value ends at the boundary of its elements' values.
> 
>> That fact is what allows the compiler to ignore mutation of the
>> buffer.
> 
> I don't know what you mean here.
> 
>> It's perfectly clear that Array is a PureValue iff T is a PureValue.
>> PureValue is nothing more than transitive value semantics.
> 
> You're almost there.  “Transitive” implies that you are going to look at
> the parts of a type to see if they are also PureValue's.  So which parts
> of the Array struct does one look at, and why?  Just tell me the
> procedure for determining whether a type is a PureValue.
 
 We look at the observable parts.  
>>> 
>>> That begs the question.  The “parts” of an Array are the observable
>>> features that are considered by equality.
>>> 
 We do not look at unobservable parts because we want flexibility to
 use things like CoW, shared immutable references, etc in our
 implementation.
>>> 
>>> IMO the important thing when it comes to functional purity is not what
>>> you *can* observe, but what you *do* observe.
>>> 
 Can you share your definition of value semantics?  
>>> 
>>> Explaining it well and in sufficient detail for this discussion takes
>>> some doing, but I think John Lakos and I share an understanding of value
>>> semantics and he has a really detailed explanation in
>>> https://www.youtube.com/watch?v=W3xI1HJUy7Q 
>>>  and
>>> https://www.youtube.com/watch?v=0EvSxHxFknM 
>>> .  He uses C++ in places,
>>> but it's not particularly advanced, and the fundamental ideas apply just
>>> as well to Swift.
>>> 
>> 
>> Super interesting talk! 
>> 
>> But consider: isn't a single value type able to represent *multiple* 
>> ethereal types?
>> 
>> std::vector is a good example. What are the salient attributes of this type? 
>> In the talk John says that
>> 
>> 1. the size is
>> 2. the values in the vector are
>> 3. the capacity, however *is not*
>> 
>> in which case std::vector would be an approximation of an ethereal type 
>> which has a list of values, and the capacity is just an artifact of the 
>> approximation. But you could also imagine an ethereal type which *does* 
>> depend of the capacity of the object, and std::vector unwittingly 
>> approximates that type too! In this case someone, unfamiliar with the 
>> implementation might use it under the assumption that capacity *is* part of 
>> the ethereal type and by extension the 

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson via swift-evolution]

> On May 16, 2016, at 1:39 AM, Dave Abrahams  wrote:
> 
> 
> on Sun May 15 2016, Tyler Fleming Cloutier  > wrote:
> 
>>On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>>on Mon May 09 2016, Matthew Johnson  wrote:
>> 
>>On May 8, 2016, at 1:51 AM, Dave Abrahams  
>> wrote:
>> 
>>on Sat May 07 2016, Andrew Trick  wrote:
>> 
>>  On May 7, 2016, at 2:04 PM, Dave Abrahams 
>>  wrote:
>> 
>>  2. Value types are not "pure" values if any part of the 
>> aggregate
>>  contains a
>>  reference whose type does not have value semantics. 
>> 
>>  Then Array is not a “pure” value (the buffer contained 
>> in an
>>  Array is a mutable reference type that on its own, 
>> definitely does
>>  *not* have value semantics). I don't think this is what you 
>> intend, and
>>  it indicates that you need to keep working on your 
>> definition.
>> 
>>It sounds like you’re changing the definition of value 
>> semantics to make it
>>impossible to define PureValue. 
>> 
>>Not on purpose.
>> 
>>Does Array have value semantics then only if T also has 
>> value
>>semantics?
>> 
>>This is a great question; I had to rewrite my response four times.
>> 
>>In my world, an Array always has value semantics if you 
>> respect the
>>boundaries of element values as defined by ==.  That means that 
>> if T is
>>a mutable reference type, you're not looking through references, 
>> because
>>== is equivalent to ===.
>> 
>>Therefore, for almost any interesting SomeConstraint that doesn't 
>> refine
>>ValueSemantics, then
>> 
>>Array
>> 
>>only has value semantics if T has value semantics, since 
>> SomeConstraint
>>presumably uses aspects of T other than reference identity.  
>> 
>>The claim has been made that Array always has value semantics,
>>implying that the array value’s boundary ends at the boundary 
>> of it’s
>>element values.
>> 
>>Yes, an array value ends at the boundary of its elements' values.
>> 
>>That fact is what allows the compiler to ignore mutation of 
>> the
>>buffer.
>> 
>>I don't know what you mean here.
>> 
>>It's perfectly clear that Array is a PureValue iff T is a 
>> PureValue.
>>PureValue is nothing more than transitive value semantics.
>> 
>>You're almost there.  “Transitive” implies that you are going to 
>> look at
>>the parts of a type to see if they are also PureValue's.  So 
>> which parts
>>of the Array struct does one look at, and why?  Just tell me the
>>procedure for determining whether a type is a PureValue.
>> 
>>We look at the observable parts.  
>> 
>>That begs the question.  The “parts” of an Array are the observable
>>features that are considered by equality.
>> 
>>We do not look at unobservable parts because we want flexibility to
>>use things like CoW, shared immutable references, etc in our
>>implementation.
>> 
>>IMO the important thing when it comes to functional purity is not what
>>you *can* observe, but what you *do* observe.
>> 
>>Can you share your definition of value semantics?  
>> 
>>Explaining it well and in sufficient detail for this discussion takes
>>some doing, but I think John Lakos and I share an understanding of value
>>semantics and he has a really detailed explanation in
>>https://www.youtube.com/watch?v=W3xI1HJUy7Q and
>>https://www.youtube.com/watch?v=0EvSxHxFknM.  He uses C++ in places,
>>but it's not particularly advanced, and the fundamental ideas apply just
>>as well to Swift.
>> 
>> Super interesting talk! 
>> 
>> But consider: isn't a single value type able to represent *multiple*
>> ethereal types?
> 
> “ethereal?”  Does he really use that term?  I don't know what it means.
> 
>> 
>> std::vector is a good example. What are the salient attributes of this
>> type? In the talk John says that
>> 
>> 1. the size is
>> 2. the values in the vector are
>> 3. the capacity, however *is not*
> 
> Yup, just like Array.  Thus the equality test for arrays ignores
> capacity.
> 
>> in which case std::vector would be an approximation of an ethereal
>> type which has a list of values, and the capacity is just an artifact
>> of the approximation. But you could also imagine an ethereal type
>> which *does* depend of the capacity of the object, and std::vector
>> unwittingly approximates that type too! In this case 

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson via swift-evolution]

> On May 15, 2016, at 1:48 PM, Dave Abrahams  wrote:
> 
> 
> on Mon May 09 2016, Matthew Johnson  > wrote:
> 
>>> On May 8, 2016, at 1:51 AM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Sat May 07 2016, Andrew Trick  wrote:
>>> 
>> 
   On May 7, 2016, at 2:04 PM, Dave Abrahams  wrote:
 
   2. Value types are not "pure" values if any part of the aggregate
   contains a
   reference whose type does not have value semantics. 
 
   Then Array is not a “pure” value (the buffer contained in an
   Array is a mutable reference type that on its own, definitely does
   *not* have value semantics). I don't think this is what you intend, and
   it indicates that you need to keep working on your definition.
 
 It sounds like you’re changing the definition of value semantics to make it
 impossible to define PureValue. 
>>> 
>>> Not on purpose.
>>> 
 Does Array have value semantics then only if T also has value
 semantics?
>>> 
>>> This is a great question; I had to rewrite my response four times.
>>> 
>>> In my world, an Array always has value semantics if you respect the
>>> boundaries of element values as defined by ==.  That means that if T is
>>> a mutable reference type, you're not looking through references, because
>>> == is equivalent to ===.
>>> 
>>> Therefore, for almost any interesting SomeConstraint that doesn't refine
>>> ValueSemantics, then
>>> 
>>> Array
>>> 
>>> only has value semantics if T has value semantics, since SomeConstraint
>>> presumably uses aspects of T other than reference identity.  
>>> 
 The claim has been made that Array always has value semantics,
 implying that the array value’s boundary ends at the boundary of it’s
 element values.
>>> 
>>> Yes, an array value ends at the boundary of its elements' values.
>>> 
 That fact is what allows the compiler to ignore mutation of the
 buffer.
>>> 
>>> I don't know what you mean here.
>>> 
 It's perfectly clear that Array is a PureValue iff T is a PureValue.
 PureValue is nothing more than transitive value semantics.
>>> 
>>> You're almost there.  “Transitive” implies that you are going to look at
>>> the parts of a type to see if they are also PureValue's.  So which parts
>>> of the Array struct does one look at, and why?  Just tell me the
>>> procedure for determining whether a type is a PureValue.
>> 
>> We look at the observable parts.  
> 
> That begs the question.  The “parts” of an Array are the observable
> features that are considered by equality.
> 
>> We do not look at unobservable parts because we want flexibility to
>> use things like CoW, shared immutable references, etc in our
>> implementation.
> 
> IMO the important thing when it comes to functional purity is not what
> you *can* observe, but what you *do* observe.
> 
>> Can you share your definition of value semantics?  
> Explaining it well and in sufficient detail for this discussion takes
> some doing

I asked for your definition of value semantics because you keep asking for a 
concise definition of PureValue.  I was trying to identify how to structure a 
definition in a way that would be acceptable to you.   

> , but I think John Lakos and I share an understanding of value
> semantics and he has a really detailed explanation in
> https://www.youtube.com/watch?v=W3xI1HJUy7Q 
>  and
> https://www.youtube.com/watch?v=0EvSxHxFknM 
> .  He uses C++ in places,
> but it's not particularly advanced, and the fundamental ideas apply just
> as well to Swift.

Thanks, good talks.  I believe I have seen earlier versions of them previously.

I’m still unsure of what structure would be acceptable to you as John doesn’t 
give a concise “here it is on one slide” definition of the kind you seem to be 
looking for with regards to pure value.  If anything, the talks demonstrate how 
nuanced this discussion is.

That said, I’ll take a shot at defining pure value using John’s terminology.  
John talks about salient attributes quite a bit.  These are the “observable 
parts” I have been talking about.  

John also makes a very strong and clear distinction between “value semantics” 
and “in-core value semantics”.  This distinction is fundamental to the 
distinction I am making.  Your definition of “value semantics” appears to 
include both what John calls “value semantics” as well as what John calls 
“in-core value semantics”.  As far as I can tell my definition of “pure value” 
aligns with what John simply calls “value semantics” (or in some cases he says 
“full value semantics”) which *excludes* what he calls “in-core value 
semantics” (including pointers).  Quoting John:

“What kind of objects do not try to represent a value?  … Pointers actually 
represent something in the middle.  They don’t represent an 

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson via swift-evolution]

> On May 16, 2016, at 10:14 AM, Dave Abrahams  wrote:
> 
> 
> on Mon May 16 2016, Matthew Johnson  wrote:
> 
>>> On May 15, 2016, at 1:53 PM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Fri May 13 2016, Matthew Johnson >> > wrote:
>>> 
>> If we’re going to hide the implementation details maybe it’s worth
>> taking advantage of the type by making the props var and using CoW.
>> 
>> What do you think about a proposal to enhance “indirect” for value
>> types and / or instances of them.  I can think of a few approaches to
>> this that we could consider.  I would be much more comfortable with
>> what you want to do if we tackle that as well.
> 
> It's a good idea that can help to make CoW easy to implement; I have
> advocated for it (not in public) in the past.  
 
 Glad to hear this.  Maybe in Swift 4?  (I know it's too early to say)
 
> People should be aware
> that the resulting automatic CoW will be suboptimal in many cases,
> because when you discover you need new storage it's usually better to
> build a new value than to copy the old one and overwrite it.
 
 How big a difference does that usually make, especially when compared
 to the reasons you would use indirect in the first place?  
>>> 
>>> Usually a big difference.
>>> 
 Wouldn't the compiler be able to do this in the automatic
 implementation in some cases
>>> 
>>> Not in any interesting cases I know of.  If you're inserting into an
>>> array and you discover you need new storage because there is more than
>>> one reference, starting by copying can double the cost of the insertion
>>> (on a large array when memory allocation is fast).
>> 
>> Of course this is true of data structures.  I wouldn’t expect the
>> compiler to provide a reasonable implementation of CoW for data
>> structures.
>> 
>> Maybe I wasn’t clear.  I was talking about domain model objects like the 
>> following:
>> 
>> struct Person {
>>  var firstName: String
>>  var lastName: String
>>  // …
>> }
>> 
>> I find it hard to believe the compiler CoW implementation would do
>> something so suboptimal as to be significant when you write to
>> firstName through an indirect instance in cases like this (which are
>> pervasive in application code).
> 
> Oh, OK.  And you want to CoW this because...?  Reducing refcount
> traffic?

Avoiding copying and refcounting.  This might be a large aggregate.  You might 
use indirect structs and CoW so that portions of the aggregate can be shared by 
more than one aggregate root (i.e. persistent data structure).

> 
 (such as writing to a stored var)?
>>> 
>>> I don't know what you mean here.
>> 
>> Continuing with the previous example, if the CoW implementation is
>> significantly better when using a memberwise initializer to construct
>> the new box rather than copy the value over from the old box and then
>> update the property that was written to it seems like the compiler
>> should be able to make that optimization in some cases.  (i.e. when
>> there exists a memberwise initializer which exposes all stored
>> properties).
> 
> Sure.
> 
> -- 
> -Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson via swift-evolution]

> On May 15, 2016, at 2:01 PM, Dave Abrahams  wrote:
> 
> 
> on Fri May 13 2016, Matthew Johnson  > wrote:
> 
>> Sent from my iPad
>> 
>>> On May 13, 2016, at 9:12 AM, Dave Abrahams  wrote:
>>> 
>>> 
 on Mon May 09 2016, Matthew Johnson  wrote:
 
   My claim is that substituting the constraint of “it has value
   semantics,” while presumably looser than the PureValue constraint, would
   not compromise the correctness of your view controller, so not only is
   the meaning of PureValue hard to define, but it doesn't buy you
   anything.  If you want to refute that, just show me the code.
 
   This is not an algorithmic use but is still perfectly valid IMO.
 
   If the properties of PureValue matter to your view controller, there's
   an algorithm somewhere that depends on those properties for its
   correctness.
 
 In many cases it may just be view configuration that depends on those
 properties.  I suppose you can call view configuration code an
 algorithm but I think that would fall outside of common usage.
>>> 
>>> It's an algorithm, or if the configuration is declarative, there's an
>>> algorithm that manipulates it.  That said, I still don't have a concrete
>>> example of how view configuration can depend on these properties.
>> 
>> The algorithm might just be "copy x bit of data to y view property,
>> etc".  That is so trivial that it feels like a stretch to call it an
>> algorithm.
> 
> Algorithms can be trivial.

Fair enough.  Although in most contexts people don’t use the word when 
discussing the trivial.

> 
>> That "algorithm" doesn't depend on this property because it executes
>> at a single point in time.  However, a view controller might depend on
>> that property in order to render properly across time (for example,
>> configuring cells as they scroll on and off screen).
> 
> The example is too abstract for me to understand.
> 
> Let me put this differently: I recognize that your concept of
> “PureValue” may be a *sufficient* condition for some generic
> algorithm/component to work, but it is never a *necessary* condition,
> because genericity (or use of a superclass or protocol type) erases
> details of the actual types involved from the point of view of the
> algorithm/component.  It doesn't matter if your type contains a class
> reference if it has value semantic properties.  My claim is that
> PureValue is an overly-restrictive constraint that makes many things
> less useful than they should be.

In many cases this is true - you don’t need more than value semantics as you 
define it.  However it is not at all true that PureValue is never necessary for 
the correctness of code.  I’m going to provide an example to the contrary below.

> 
>> This property allows us to separate values from non-local mutation and
>> make such separation a requirement.  Rather than observing mutations
>> of objects with KVO, etc we might prefer to observe something that
>> provides a new aggregate value instead, while requiring the entire
>> aggregate value itself to be (observably) immutable at all times
>> (because we stored it with a let property locally).  This can make it
>> easier to reason about correct behavior of your code.  But it doesn't
>> work unless all visible parts of the aggregate are immutable.
>> 
>> If you're not familiar with Elm, Redux, etc it might be worth taking
>> a look.  
> 
> That's a pretty broad link.  At which parts do you think I should look?

The piece that matters here is state management.  The core concept is to 
tightly control how mutations happen.  It is modeled in terms of state type T, 
an initial value t, an action type A (instances of which are mutation commands, 
as in the command pattern), and a reducer function (T, A) -> T which produces a 
new state.

Here’s a toy implementation that is somewhat simplistic but captures the 
essence of the concept:

class Store {
typealias Reducer = (State, Action) -> State

var stateHistory: [State]
let reducer: Reducer

init(initialState: State, reducer: Reducer) {
stateHistory = [initialState]
self.reducer = reducer
}

func applyAction(action: Action) {
let newState = reducer(stateHistory.last!, action)
stateHistory.append(newState)
}

var currentState: State {
return stateHistory.last!
}

var canUndo: Bool {
return stateHistory.count > 1
}

func undo() {
if canUndo {
stateHistory.popLast()
}
}
}

This design relies on State being a PureValue.  The whole idea is that the only 
way any path of observation rooted at currentState can change is when the 
reducer returns a new state when it is called by `applyAction`.  That guarantee 
cannot be provided by value semantics alone under your definition of value 
semantics.  

Re: [swift-evolution] Union instead of Optional

[Joe Groff via swift-evolution]

Unlike sum types, such as Swift enums, unions don't have parametricity, because 
(T \union Nil) \union Nil == T \union Nil. This means that things like 
collections containing Optionals don't just work, since it becomes impossible 
for operations like 'find' to distinguish 'nil' as a value in the container 
from 'nil' as a "not found" result. Languages without sum types tend to 
compensate by growing multiple "nil"-like values—ObjC has NSNull, Javascript 
has undefined and null, VB has Null, Nothing, *and* None, and so on.

-Joe

> On May 14, 2016, at 7:33 PM, Cao Jiannan via swift-evolution 
>  wrote:
> 
> 
> It’s kind of same idea of TypeScipt 2, at 46:21 in this video.
> 
> https://channel9.msdn.com/Events/Build/2016/B881
> 
> <屏幕快照 2016-05-15 10.20.36.png>
> 
> 
>> 
>> 2016-2-16 GMT+8 14:36:28
>> Hi all,
>> 
>> I think the best way to solve the either problem is to separate it from 
>> generic. 
>> Optional and Either shouldn’t work the same way of generic type. 
>> It’s just a represent of multiple type in one location.
>> 
>> Using an old friend, Union in C.
>> union {
>>  case firstType
>>  case secondType
>> }
>> 
>> This is the final solution for the sub typing problem of optional.
>> 
>> A  == union(A,A)
>> union(A,B) == union(B,A)
>> B == union(B,B)
>> 
>> B is subtype of union(A,B)
>> A is subtype of union(A,B)
>> union(A,B,C) is subtype of union(A,B,C,D,…)
>> 
>> suppose 
>> a is subclass of A
>> b is subclass of B, then
>>  union(a,B) is subtype of union(A,B)
>>  union(A,b) is subtype of union(A,B)
>>  union(a,b) is subtype of union(a,B)
>>  union(a,b) is subtype of union(A,b)
>> 
>> union can have as many case as possible. e.g., union(A,B,C,D,…)
>> 
>> So the Optional should be union(UITableView, None)
>> and Optional should be union(MyTableView, None), which is 
>> subclass of union(UITableView, None)
>> 
>> This is a final rational solution. I think.
>> 
>> -Jiannan
>> 
> 
> 
> 
> 
> ___
> 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

Re: [swift-evolution] [RFD] Non-Self Protocol Requirements

[Vladimir.S via swift-evolution]

On 16.05.2016 18:06, Patrick Smith via swift-evolution wrote:

let foo: [Double] = Double[int32, int8, double, cgfloat, float] // As if
you had written Double(…) around each item


I really like this suggestion. Actually IMO we don't need explicit type 
declaration here:


// clearly it is an array of Double
let foo = Double[int32, int8, double, cgfloat, float]

We can use the same feature for other types like
let foo = String[1, 1.0, true]

Or even some complex type:
let foo = ComplexType[1, 1.0, true]

But I really don't like this:
//let foo: [Double] = [int32, int8, double, cgfloat, float](Double.init)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Tino Heth via swift-evolution]

hi there,

just skimmed through the bigger part of this thread — it's a really interesting 
discussion, but wouldn't it be worth a topic on its own?
The title of this message addresses a much simpler question (that imho still 
deserves some answers ;-)

Tino
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Union instead of Optional

[Michael Peternell via swift-evolution]

> Am 16.05.2016 um 12:07 schrieb Austin Zheng via swift-evolution 
> :
> 
> Precisely. To me unions are to enums with associated type the same way tuples 
> are to structs. One is named, has well-defined semantics, can conform to 
> protocols, can have complex internal structure, can have methods, etc. The 
> other is ad-hoc and lightweight, easy to define at the site of use, best 
> suited for simple purposes, has special syntax to support it. 
> 
> Even if we can extend tuples in the future, though, I wouldn't want structs 
> to go away. When exceeding some level of complexity structs are just more 
> explicit than tuples, and therefore easier to understand.
> 
> Finally, please note that Ceylon is a pervasively object-oriented language 
> with a single root superclass. Neither of those is true for Swift, which 
> chooses to solve a lot of problems in a different (and I would argue, 
> superior) way. So solutions that might work well in Ceylon might not be 
> suited for Swift, at least not without modification, and vice versa. The core 
> team could certainly have chosen to model Swift's type system after that of 
> e.g. Scala, but they chose not to, and I think they did so for good reason.

Swift has a root class, it is called SwiftObject and it's visible from 
Objective-C ;) Just thinking about it.. it makes sense: the whole 
reference-counting-stuff has to live somewhere in the object, and there has to 
be some kind of isa-pointer to allow for subclassing (and Objective-C 
interoperability). So there is some common behavior regarding all classes 
defined from Swift (they all implement retain, release, autorelease, isEqual:, 
class, respondsToSelector:, the whole NSObject-protocol...) => what I want to 
express: Java has a root-class, C++ has no root class - that's uncontested; but 
Swift is somewhere in-between IMHO.

And for enums and unions.. I think they are different. enums are "sum-types" 
and unions are... well... "union-types", when you think of data types as sets. 
E.g. if A, B are data types (sets), then an enum that can be either anA(A) or 
aB(B) can be thought of as the set A+B (and if A \intersect B \not\eq 
\emptyset, you can think of this as (0,A)\union (1,B) ). A union B is not the 
same. In C, the unions are not even safe, because they are not discriminated in 
any way. In Swift they make an isomorphic set if A and B are disjoint. If 
A=String and B=Int, A `enum` B is isomorphic to A `union` B (sorry for abusing 
Haskell syntax :-/ ). But if A=Iterable and B=Array, they are 
not the same, because now A is a superset of B. So A `enum` B is a strict 
superset of A `union` B (== A). I can already imagine weird bugs coming to the 
surface from this distinction, all of which can be solved by disallowing union 
types altogether.

Therefore I think that unions are not worth the trouble at all. And they are 
even possible right now: Instead of writing

union MyUnion { Int, String }
// or typealias MyUnion = (Int | String) // ?

you'd have to write

protocol MyUnion {}
extension Int: MyUnion {}
extension String: MyUnion {}

The two definitions are basically equivalent, and the second is already valid 
Swift.

I have used unions a few times in C though, e.g. for converting from void* to 
int or stuff like that, at a time when I didn't know about reinterpret_cast 
(Swift: unsafeBitcast) yet. The few occasions where they are use in the C 
standard library, they are always discriminated, like a union between a 
struct(int type, float foo, ...) and another struct(int type, char bar[20], 
...) where the type parameter is in both values and can be used to distinguish 
them. In Swift they are always distinguishable because of runtime type 
information (except for the case described above), so you can as well just use 
an enum and make that information obvious. To unpack the information you can 
use `if let` when dealing with a union, and you can use `if case` or `switch` 
when dealing with an enum. I don't see how unions would be more convenient to 
be worth the trouble. Swift unions would be like (C unions + RTTI (runtime type 
information)), with RTTI replacing the discriminator element of enums, except 
when the types overlap. So I doubt that anyone will find a decent (realistic!) 
use-case that is not just as easily (and conveniently) implemented using enums. 
I think I just proved that there is no such use case ;) The best way to 
convince me otherwise would be to provide a realistic piece of example code.

Regards,
Michael

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

Hi Everyone,

As we get deeper into the Swift 3 release cycle, we’re beginning to have a more 
precise understanding about what the release will shape up to be.  Ted posted 
details of the Swift 3 release process last week 
(https://swift.org/blog/swift-3-0-release-process/) and I just updated the main 
swift-evolution README.md file (https://github.com/apple/swift-evolution) with 
some updated details about the goals of Swift 3.

This release is shaping up to be a really phenomenal release that will redefine 
the feel of Swift and make a major leap towards maturing the Swift language and 
development experience.  We have had a focus on getting to source stability, 
with the forward-looking goal of making Swift 4 as source compatible with Swift 
3 as we can reasonably accomplish.  It tackled API naming head on (which is one 
of the hardest problems in computer science [1]), made major improvements to 
the consistency and feel of the language, and has several nice across the board 
additions.

That said, it is also clear at this point that some of the loftier goals that 
we started out with aren’t going to fit into the release - including some of 
the most important generics features needed in order to lock down the ABI of 
the standard library. As such, the generics and ABI stability goals will roll 
into a future release of Swift, where I expect them to be the *highest* 
priority features to get done.

I expect discussion and planning for Swift 3.x and Swift 4 to start sometime 
around August of this year.  Until then, it is very important that we as a 
community stay focused on the goals of Swift 3: I’d really prefer us all to 
resist the urge to discuss major blue sky features for future releases.  We 
would also like to put a significant amount of effort into bug fixing and 
quality refinements as well, which means that the core team will be proactively 
deferring evolution proposals to later releases that don’t align with the Swift 
3 goals, especially those that are strictly additive.

Thank you for all of the amazing community that has developed on this list, it 
is great to work with you all!  Let us know if you have any questions,

-Chris

[1] It is well known that the two hard problems in Computer Science are naming, 
cache invalidation, and off-by-one errors.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal/Pitch] Function decorators

[Karl via swift-evolution]

> On 16 May 2016, at 16:25, Erica Sadun  wrote:
> 
>> On May 8, 2016, at 10:33 AM, Karl Wagner via swift-evolution 
>> > wrote:
>> 
>> 
>>> On 4 May 2016, at 00:46, Aleksandar Petrovic via swift-evolution 
>>> > wrote:
>>> 
>>> Hi swift-evolution,
>>> 
>>> I want to apologize in advance for my clumsy English. It's (obviously) not 
>>> my first language.
>>> 
>>> Recent discussion about property behaviours reminded me of function 
>>> decorators in Python. I think decorators can nicely fit in Swift, too.
>>> 
>>> First, a bit of explanation for the uninitiated. Decorator is a function 
>>> that transform other function - it receives some function and returns a 
>>> function of the same signature. Lets make some dead simple decorator:
> 
> 
> In Objective-C, you can add a category that will entirely replace an existing 
> method. Could using decorators allow us to add behaviors to methods to extend 
> their behavior without overwriting those methods? Here is an example of what 
> I'm thinking.
> 
> extension UIView {
>decorate func somethingElse(...) {
>  // performs existing behavior of somethingElse
> ... adds new behavior ...
>}
> }
> 
> Context: I was asking about whether this kind of "extend rather than replace 
> or subclass" behavior were possible in Swift, and was told that "decorators" 
> might be the right technology to implement it.
> 
> Thanks in advance for any insight.
> 
> -- E
> 

I was thinking more along the lines of property behaviours, which are specified 
at compile-time. Decorating an existing function inside an extension would only 
be possible for overridable functions in non-final types (otherwise the 
functions may have been inlined). But yeah, theoretically I think you could 
capture the existing function pointer and replace it in the vtable with a 
decorated one. That is basically what you’d do in Objective-C today (getting 
the IMP for a selector, making an IMP from a closure and switch them in the 
dispatch table, then call original IMP from your closure).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [RFD] Non-Self Protocol Requirements

[Patrick Smith via swift-evolution]

Yes, something like this would be handy! Even the ability to coerce from one 
type to another, if that destination type has a keyless initialiser for the 
source type.

Here’s some imaginary syntax for with Erica’s array example. I would prefer a 
way to not have a separate type for ‘DoubleSource’ if possible.

let foo: [Double] = Double[int32, int8, double, cgfloat, float] // As if you 
had written Double(…) around each item

or

let foo: [Double] = [int32, int8, double, cgfloat, float](Double.init) // // As 
if you had written Double(…) around each item


Here’s another use case I’ve had:

enum Deferred {
typealias UseResult = () throws -> Result

case unit(UseResult)
case future(((UseResult) -> ()) -> ())

init(_ subroutine: UseResult) {
self = .unit(subroutine)
}
}

Instead of this:

struct Example {
func next() -> Deferred {
return Deferred{ 42 }
}
}

It would be nice to be able to do this:

struct Example {
func next() -> Deferred {
return { 42 }
}
}

I don’t know if that’s playing with fire, but it would be seemingly nice for 
Swift to automatically infer what I want.


> On 17 May 2016, at 12:15 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> The following situation has come up for me now and then: I want to work with 
> groups of types that share a common behavior, but that behavior is not 
> sourced in the implementation of the Self type but rather in a secondary 
> type.  Specifically, could Swift be extended to introduce a protocol 
> requirement that discusses how a type is used by a secondary type and not the 
> kind of member provided directly by the type. For example:
> 
> // These are all numbers
> let int32: Int32 = 1; let int8: Int8 = 1
> let double: Double = 1.0; let cgfloat: CGFloat = 1.0; let float: Float = 1
> 
> // They can all be converted to Double using Double.init
> Double(int32); Double(int8); Double(double); Double(cgfloat); Double(float)
> 
> // A heterogeneous collection cannot be unified into a single protocol
> let foo: [Any] = [int32, int8, double, cgfloat, float]
> foo.map{ Double($0) } // Can't work, Any doesn't make any sense here
> 
> The kind of thing I am looking for is something like this:
> 
> protocol DoubleSource {
> Double.init(Self)
> }
> 
> In other words, the functionality constraint is not provided by the base type 
> but by a second type to which the base type is a parameter.
> 
> My use case is for unrelated types (that is, there's no inheritance 
> relationship like you'd find in `UISwitch` and `UISlider`, for example -- 
> both of which are `UIView` and `UIControl`), where there is a secondary type 
> that implements behavior with the same signature for these separate types, 
> such as the Double initializer. Where this pops up the most is in working 
> with Sprite/SceneKit, GamePlayKit, QuartzCore, Accelerate, unifying my 
> numeric values so I can mix and match calls and clean up the flow where some 
> calls require CGPoint, others need float2, etc. Ideally I would be able to 
> 
> extension DoubleSource {
> func bar() -> T {
> let value = Double.init(self)
> // do something with value; return T of some type
> }
> }
> 
> let foo: [DoubleSource] = [int32, int8, double, cgfloat, float]
> foo.map{ bar($0) } // would work
> 
> Would something like this be a valuable direction to extend Swift? Is it 
> something found in other languages? Does this kind of requirement have a 
> name? Is it *pragmatically* possible to introduce it in Swift?
> 
> Thanks in advance for your thoughts and insights.
> 
> -- E
> 
> ___
> 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

Re: [swift-evolution] Union instead of Optional

[Leonardo Pessoa via swift-evolution]

I don't really get it why the compiler is to complain about the if block not 
having an else in this case. That seems like a bug that will push us to write 
unnecessary code. The compiler is not capable of inferring there are more 
conditions to evaluate in an if statement opposed to a switch statement. Even 
with the proposed union the compiler cannot infer the need for an else block 
here because the programmer might not want to do anything else with whatever 
doesn't match the first condition.

On the other hand, if you intend to add to this proposal that a switch 
statement could evaluate the type of the value like the following code, I'd 
agree with you. I'm just not sure one could do this as of today.

func input(value: (A | B | C)) {
   switch value.type {
  case A:
 ...
  case B:
 ...
  default:
 // here the compiler knows I didn't cover all possible types
 // adding 'case C' here makes 'default' unnecessary
   }
}

I would add to this discussion if this would be the best syntax for the 
proposed type. I'd think about 'union' as it matched other existing 
syntax and is a bit more explicit about what's going on the code.

> On 16 May 2016, at 7:55 am, Cao Jiannan via swift-evolution 
>  wrote:
> 
> Hi Austin,
> 
> let me repeat the example so that clarify my point from this example.
> 
> protocol cannot do this:
> 
> func input(value: ProtocolForABC) {
> print(value.someCommonProperty)
> 
> if value is A {
> 
> } else if value is B {
> 
> } else if value is C {
> 
> } else {
> // There no other cases, but compiler will not trigger a warning.
> }
> }
> 
> The compiler will not know your protocol is only conformed to these three 
> classes.
> So the else block will not trigger a warning.
> 
> - Jiannan
> 
> 
>> 在 2016年5月16日，18:37，Austin Zheng  写道：
>> 
>> I'm sorry, but I don't understand the point you are trying to make.
>> 
>> If you pass in a value of type (A | B | C) to a function, what might you 
>> want to do with that value?
>> 
>> If you want to do one thing if the value is type A, something else if the 
>> value is type B, and something else if the value is type C, then you need to 
>> switch or otherwise type check the value at runtime. You can't get around 
>> this, no matter whether you use enums, protocols, generics, or union type.
>> 
>> If you want it to do something that A, B, and C all support, use a generic 
>> and/or a protocol. In this case limiting the inputs to only those three 
>> types is probably a design smell. The whole point of a shared interface is 
>> that it only matters that the interface is properly implemented by a type, 
>> not what that type is.
>> 
>> If you don't care about doing anything with the value, just make your 
>> function generic: func(input: T).
>> 
>> Austin
> 
> ___
> 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

Re: [swift-evolution] [Proposal/Pitch] Function decorators

[apetro...@outlook.com via swift-evolution]

Well, yes and no. A decorator receives a method and returns a new method, and 
it's up to implementation what will happen in the new method - it can perform 
some operations before calling the original method, or doing something after 
the original method is called, or not calling the original method at all. But a 
decorator must be applied to the function in compile time, so changing the 
behavior of functions from some library we don't have source (like UIView, in 
your example) wouldn't be possible.

At least according to my original proposal. The proposal can be changed, but we 
need to invent some new syntax for such decorators.

Alex


On May 16, 2016 at 16:25:08, Erica Sadun (er...@ericasadun.com) wrote:

On May 8, 2016, at 10:33 AM, Karl Wagner via swift-evolution 
 wrote:


On 4 May 2016, at 00:46, Aleksandar Petrovic via swift-evolution 
 wrote:

Hi swift-evolution,

I want to apologize in advance for my clumsy English. It's (obviously) not my 
first language.

Recent discussion about property behaviours reminded me of function decorators 
in Python. I think decorators can nicely fit in Swift, too.

First, a bit of explanation for the uninitiated. Decorator is a function that 
transform other function - it receives some function and returns a function of 
the same signature. Lets make some dead simple decorator:


In Objective-C, you can add a category that will entirely replace an existing 
method. Could using decorators allow us to add behaviors to methods to extend 
their behavior without overwriting those methods? Here is an example of what 
I'm thinking.

extension UIView {
   decorate func somethingElse(...) {
         // performs existing behavior of somethingElse
        ... adds new behavior ...
   }
}

Context: I was asking about whether this kind of "extend rather than replace or 
subclass" behavior were possible in Swift, and was told that "decorators" might 
be the right technology to implement it.

Thanks in advance for any insight.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

[Brad Hilton via swift-evolution]

>* What is your evaluation of the proposal?

+1. Having consistent conventions makes sense to me. I’d prefer `Initializable` 
to `Creatable` which sounds weird to me, but otherwise sounds great.

>* Is the problem being addressed significant enough to warrant a change to 
>Swift?

I think semantic consistency is important.

> * Does this proposal fit well with the feel and direction of Swift?

Yes.

> * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?

I don’t know if I’ve seen a similar standard in other languages.

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

I’ve been following this proposal for weeks and if approved it will influence 
my work.


> Hello Swift community,
> 
> The review of "SE-0041: Updating Protocol Naming Conventions for Conversions" 
> begins now and runs through May 16. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change to 
> Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

[Tony Allevato via swift-evolution]

On Tue, May 10, 2016 at 11:48 AM Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0041: Updating Protocol Naming Conventions for
> Conversions" begins now and runs through May 16. The proposal is available
> here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
>

+1 with the newly proposed Initializable/Representable names. Initializable
just fits perfectly with the fact that Swift has things called initializers
and is a vast improvement over Creatable. Representable to denote the other
direction makes sense compared to existing Cocoa APIs that use
*Representation in their name.


> * Is the problem being addressed significant enough to warrant a
> change to Swift?
>

Yes. Many developers use stdlib as guidance when designing their own APIs
and having the standard library be internally consistent sets a good
example. These recommendations should also be hoisted into the API naming
guidelines documentation so that people can easily cite it, as opposed to
just saying "note the pattern that exists" (this is helpful when writing
team-specific style guides and for enforcing conventions in code reviews).


> * Does this proposal fit well with the feel and direction of Swift?
>

Yes, it makes the language more consistent.


> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>

None that handle conversions in this way using protocols.


> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>

I read the proposal, the message with the updated names afterwards, and
loosely followed the e-mail threads.


>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
> ___
> 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

Re: [swift-evolution] [Proposal/Pitch] Function decorators

[Erica Sadun via swift-evolution]

> On May 8, 2016, at 10:33 AM, Karl Wagner via swift-evolution 
>  wrote:
> 
> 
>> On 4 May 2016, at 00:46, Aleksandar Petrovic via swift-evolution 
>> > wrote:
>> 
>> Hi swift-evolution,
>> 
>> I want to apologize in advance for my clumsy English. It's (obviously) not 
>> my first language.
>> 
>> Recent discussion about property behaviours reminded me of function 
>> decorators in Python. I think decorators can nicely fit in Swift, too.
>> 
>> First, a bit of explanation for the uninitiated. Decorator is a function 
>> that transform other function - it receives some function and returns a 
>> function of the same signature. Lets make some dead simple decorator:


In Objective-C, you can add a category that will entirely replace an existing 
method. Could using decorators allow us to add behaviors to methods to extend 
their behavior without overwriting those methods? Here is an example of what 
I'm thinking.

extension UIView {
   decorate func somethingElse(...) {
 // performs existing behavior of somethingElse
... adds new behavior ...
   }
}

Context: I was asking about whether this kind of "extend rather than replace or 
subclass" behavior were possible in Swift, and was told that "decorators" might 
be the right technology to implement it.

Thanks in advance for any insight.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [RFD] Non-Self Protocol Requirements

[Erica Sadun via swift-evolution]

The following situation has come up for me now and then: I want to work with 
groups of types that share a common behavior, but that behavior is not sourced 
in the implementation of the Self type but rather in a secondary type.  
Specifically, could Swift be extended to introduce a protocol requirement that 
discusses how a type is used by a secondary type and not the kind of member 
provided directly by the type. For example:

// These are all numbers
let int32: Int32 = 1; let int8: Int8 = 1
let double: Double = 1.0; let cgfloat: CGFloat = 1.0; let float: Float = 1

// They can all be converted to Double using Double.init
Double(int32); Double(int8); Double(double); Double(cgfloat); Double(float)

// A heterogeneous collection cannot be unified into a single protocol
let foo: [Any] = [int32, int8, double, cgfloat, float]
foo.map{ Double($0) } // Can't work, Any doesn't make any sense here

The kind of thing I am looking for is something like this:

protocol DoubleSource {
Double.init(Self)
}

In other words, the functionality constraint is not provided by the base type 
but by a second type to which the base type is a parameter.

My use case is for unrelated types (that is, there's no inheritance 
relationship like you'd find in `UISwitch` and `UISlider`, for example -- both 
of which are `UIView` and `UIControl`), where there is a secondary type that 
implements behavior with the same signature for these separate types, such as 
the Double initializer. Where this pops up the most is in working with 
Sprite/SceneKit, GamePlayKit, QuartzCore, Accelerate, unifying my numeric 
values so I can mix and match calls and clean up the flow where some calls 
require CGPoint, others need float2, etc. Ideally I would be able to 

extension DoubleSource {
func bar() -> T {
let value = Double.init(self)
// do something with value; return T of some type
}
}

let foo: [DoubleSource] = [int32, int8, double, cgfloat, float]
foo.map{ bar($0) } // would work

Would something like this be a valuable direction to extend Swift? Is it 
something found in other languages? Does this kind of requirement have a name? 
Is it *pragmatically* possible to introduce it in Swift?

Thanks in advance for your thoughts and insights.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Union instead of Optional

[Leonardo Pessoa via swift-evolution]

I can understand this proposal nite and I don't really think they're related to 
enums at all. You can today achieve the very same behaviour using an empty 
protocol.

protocol P { }

class A : P { }
class B : P { }
struct C : P { }

func test(value : P) { }

IMO, the proposed syntax will only create a shortcut for this. And we'd still 
need to test type and cast the to get anything useful. My question now is: is 
this such a common practice that justifies the shortcut?

-Original Message-
From: "Haravikk via swift-evolution" 
Sent: ‎16/‎05/‎2016 07:35 AM
To: "Austin Zheng" 
Cc: "Adrian Zubarev via swift-evolution" ; "Cao 
Jiannan" 
Subject: Re: [swift-evolution] Union instead of Optional


> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution 
>  wrote:
> 
> If A, B, and C are not related via protocol or class inheritance, then there 
> is almost nothing you can do with value. Otherwise you still need to test 
> against the concrete type using a case statement or a if-else ladder.

I think that a case statement or similar syntax will still be needed, and the 
case names would just be the types themselves. This would work best with 
support for type-narrowing, for example:

func someMethod(value:(A|B|C)) {
switch (value) {
case .A:
value.someMethodForTypeA()
case .B:
value.someMethodForTypeB()
case .C:
value.someMethodForTypeC()
}
}

A union should really just be though of as a lightweight, restricted form of 
enum that can be declared in a quick ad-hoc fashion, similar to how tuples are 
a simpler form of struct.

I’m generally a +1 for the feature, but I’d be interested to hear about how 
well equipped the compiler is for optimising something like this. In most cases 
an Optional covers what I need, and in more complex cases I’d probably declare 
overloads for each type (i.e- someMethod(value:A), someMethod(value:B) etc.); 
unions could make the latter case simpler, but will the compiler produce the 
same code behind the scenes, i.e- by isolating what’s unique to each type?
___
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

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson via swift-evolution]

> On May 15, 2016, at 1:53 PM, Dave Abrahams  wrote:
> 
> 
> on Fri May 13 2016, Matthew Johnson  > wrote:
> 
>> Sent from my iPad
>> 
>>> On May 13, 2016, at 9:19 AM, Dave Abrahams  wrote:
>>> 
>>> 
 on Mon May 09 2016, Matthew Johnson  wrote:
 
   Remember that the only value semantic reference types are immutable, so
   the struct rendition of such types has only immutable properties.
   Personally, I don't think that transforming
 
  struct X {
...
  private:
let prop1: Type1
let prop2: Type2
let prop2: Type3
  }
 
   into
 
  struct X {
 ...
  private:
class Storage {
  let prop1: Type1
  let prop2: Type2
  let prop2: Type3
}
let value: Storage
  }
 
   is so awful if you find you need to optimize away some reference
   counting manually; you just need to add “.value” to property accesses in
   X's methods, and this doesn't require any forwarding.
 
 It’s not too awful but it does expose implementation details.  
>>> 
>>> How?  All the changes are under “private”
>> 
>> Sorry, I didn't notice private.  Probably because I am thinking of model 
>> types which expose their stored properties.
>> 
 If we’re going to hide the implementation details maybe it’s worth
 taking advantage of the type by making the props var and using CoW.
 
 What do you think about a proposal to enhance “indirect” for value
 types and / or instances of them.  I can think of a few approaches to
 this that we could consider.  I would be much more comfortable with
 what you want to do if we tackle that as well.
>>> 
>>> It's a good idea that can help to make CoW easy to implement; I have
>>> advocated for it (not in public) in the past.  
>> 
>> Glad to hear this.  Maybe in Swift 4?  (I know it's too early to say)
>> 
>>> People should be aware
>>> that the resulting automatic CoW will be suboptimal in many cases,
>>> because when you discover you need new storage it's usually better to
>>> build a new value than to copy the old one and overwrite it.
>> 
>> How big a difference does that usually make, especially when compared
>> to the reasons you would use indirect in the first place?  
> 
> Usually a big difference.
> 
>> Wouldn't the compiler be able to do this in the automatic
>> implementation in some cases
> 
> Not in any interesting cases I know of.  If you're inserting into an
> array and you discover you need new storage because there is more than
> one reference, starting by copying can double the cost of the insertion
> (on a large array when memory allocation is fast).

Of course this is true of data structures.  I wouldn’t expect the compiler to 
provide a reasonable implementation of CoW for data structures.

Maybe I wasn’t clear.  I was talking about domain model objects like the 
following:

struct Person {
  var firstName: String
  var lastName: String
  // …
}

I find it hard to believe the compiler CoW implementation would do something so 
suboptimal as to be significant when you write to firstName through an indirect 
instance in cases like this (which are pervasive in application code).

> 
>> (such as writing to a stored var)?
> 
> I don't know what you mean here.

Continuing with the previous example, if the CoW implementation is 
significantly better when using a memberwise initializer to construct the new 
box rather than copy the value over from the old box and then update the 
property that was written to it seems like the compiler should be able to make 
that optimization in some cases.  (i.e. when there exists a memberwise 
initializer which exposes all stored properties).

> 
>> Would it be possible to design indirect value types in a way that
>> allows a transition to manual control of CoW without breaking calling
>> code if that becomes necessary?
> 
> Sure, anything is possible in design, and in a feature like this I would
> of course want that capability.  It isn't the right time (for me) to try
> to figure it all out though :-)

Cool.  Not trying to push for it now.  Hopefully it has a chance in Swift 4.

> 
> -- 
> -Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Jeremy Pereira via swift-evolution]

Hi,

I’m a +1 on the proposal, I think it’s a no brainer, but I do have one 
question...

What is the reasoning behind repeating the module name in the type name? e.g we 
have `Dispatch.DispatchQueue`. Why not `Dispatch.Queue`? It seems a bit 
pointless for the Swift team to go to all that effort to give us name spaces 
and then for us to ignore them.


> On 13 May 2016, at 19:36, Matt Wright via swift-evolution 
>  wrote:
> 
> [Apologies for the weird threading, I missed the original email to the list 
> so I can’t reply to it directly]
> 
> I just wanted to let the list know that I updated proposal SE-0088 to fix the 
> typos and include a more complete listing of the Dispatch module after the 
> transformations in the proposal have been applied. Additionally, I’ve been 
> keeping up with some of the feedback in this review thread and looking to see 
> which ones would be best applied to the proposal. Though it should be made 
> clear, this particular update only covers fixing the inconsistencies in my 
> original proposal and providing a more complete overview of the module layout.
> 
> Similar to the changes in Foundation that are proposed on swift-evolution, I 
> don’t expect all of the changes in libdispatch will be able to go through 
> this process. As this is a large change (and, hopefully, a step forwards) to 
> libdispatch I believe it is important to bring it to the swift-evolution list 
> and take away your feedback for inclusion in future iterations of the module.
> 
> Thanks again for your continued feedback,
> Matt
> 
>> On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> Hello Swift community,
>> 
>> The review of "SE-0088: Modernize libdispatch for Swift 3 naming 
>> conventions" begins now and runs through May 17. The proposal is available 
>> here:
>> 
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to the direction of Swift. 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>> 
>>* What is your evaluation of the proposal?
>>* Is the problem being addressed significant enough to warrant a 
>> change to Swift?
>>* Does this proposal fit well with the feel and direction of Swift?
>>* If you have used other languages or libraries with a similar 
>> feature, how do you feel that this proposal compares to those?
>>* How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> 
>> 
>> ___
>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Vladimir.S via swift-evolution]

FWIW, totally agree with this opinion. I also don't understand why "poor 
beginner who would start typing swift code before reading the manual" 
becomes so important when we decide to accept or not some new feature or 
change. Are we working on language that must be used just to teach 
children/beginners for programming or the main purpose of Swift is 
developing of real(often complex) software products?


Please don't tell me that Swift *can* be used to teach children/beginners, 
I know this, and I believe this is good, and only very basic 
syntax/features will be used for this.


On 16.05.2016 10:46, L. Mihalkovic via swift-evolution wrote:

{bracket}I have watched some of the past discussion in the archive and
noticed a number of situations when good proposals get derailed in the name
of how difficult the syntax would become for the poor beginner who would
start typing swift code before reading the manual. My depiction is a bit
itself of an exageration, but if we all thing about it, I am sure we can
name one such proposal. Programming is not a magical activity that one
should be able to perform without any learning curve, in the name of a
universal intuition guiding us all in the right direction. I would even
wager that the more languages one learns, the easier it becomes to make
wrong assumptions based on how familiar certain patterns or notions
seem{/bracket}

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [proposal] Union Type

[Cao Jiannan via swift-evolution]

Union is far better then generic enum/protocol solution.
* It can extend the original enum and make it powerful.

enum ResultDataType {
case Music
case Video
case File
}

enum FailureType {
case HTTP404
case HTTP502
}

enum FailureTypev2 {
case HTTP451
}

typealias Result = (ResultDataType | FailureType | FailureTypev2)

* It keeps the code clear and does not need developer to announce some 
unnecessary protocols or enums.
like UnionOf3 or ProtocolForABC

* It is easy to wrap original value into an union type.
let a = A()
let union: (A|B|C) = a // Automatically wrap.

* Compiler might search their common properties, and methods, then mark 
them as a member of the union type.
print(value.someCommonProperty) // Compiler will know their 
common properties automatically.


* Compiler know the union type exactly composed with which types, 
better than only know which protocol.
func input(value: ProtocolForABC) {
if value is A {

} else if value is B {

} else if value is C {

} else {
// There are other cases? Compiler doesn't know
}
}

* Original types and union types can have a rational relationship 
between each other. 
   Original type is a sub-type of union types contain it.

var fn0: A->Void = {print(v0)}
var fn1: (A|B)->Void = {print(v0)}

fn0 = fn1 // Original Type and Union Type has a sub-typing 
relationship, OK

var fn2: (A|B|C)->Void = {print($0)}

fn0 = fn2 // OK
fn1 = fn2 // OK


* It is also easy to compare with value of original type.
union == a // Can be compared, Yes for most cases.

* And the most important part, It can replace Optional.
let string: String?
is same to 
let string: (String | None)  instead of let string: 
Optional


I really think the union type is a good supplement for Swift. Make the language 
rational.
And the It is also really good for Reactive Programming.   

- Jiannan  

> 下面是被转发的邮件：
> 
> 发件人: Haravikk 
> 主题: 回复： [swift-evolution] Union instead of Optional
> 日期: 2016年5月16日 GMT+8 18:35:25
> 收件人: Austin Zheng 
> 抄送: Cao Jiannan , Adrian Zubarev via swift-evolution 
> 
> 
> 
>> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution 
>>  wrote:
>> 
>> If A, B, and C are not related via protocol or class inheritance, then there 
>> is almost nothing you can do with value. Otherwise you still need to test 
>> against the concrete type using a case statement or a if-else ladder.
> 
> I think that a case statement or similar syntax will still be needed, and the 
> case names would just be the types themselves. This would work best with 
> support for type-narrowing, for example:
> 
>   func someMethod(value:(A|B|C)) {
>   switch (value) {
>   case .A:
>   value.someMethodForTypeA()
>   case .B:
>   value.someMethodForTypeB()
>   case .C:
>   value.someMethodForTypeC()
>   }
>   }
> 
> A union should really just be though of as a lightweight, restricted form of 
> enum that can be declared in a quick ad-hoc fashion, similar to how tuples 
> are a simpler form of struct.
> 
> I’m generally a +1 for the feature, but I’d be interested to hear about how 
> well equipped the compiler is for optimising something like this. In most 
> cases an Optional covers what I need, and in more complex cases I’d probably 
> declare overloads for each type (i.e- someMethod(value:A), 
> someMethod(value:B) etc.); unions could make the latter case simpler, but 
> will the compiler produce the same code behind the scenes, i.e- by isolating 
> what’s unique to each type?

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Union instead of Optional

[Cao Jiannan via swift-evolution]

Hi Austin,

let me repeat the example so that clarify my point from this example.

protocol cannot do this:

func input(value: ProtocolForABC) {
print(value.someCommonProperty)

if value is A {

} else if value is B {

} else if value is C {

} else {
// There no other cases, but compiler will not trigger a warning.
}
}

The compiler will not know your protocol is only conformed to these three 
classes.
So the else block will not trigger a warning.

- Jiannan


> 在 2016年5月16日，18:37，Austin Zheng  写道：
> 
> I'm sorry, but I don't understand the point you are trying to make.
> 
> If you pass in a value of type (A | B | C) to a function, what might you want 
> to do with that value?
> 
> If you want to do one thing if the value is type A, something else if the 
> value is type B, and something else if the value is type C, then you need to 
> switch or otherwise type check the value at runtime. You can't get around 
> this, no matter whether you use enums, protocols, generics, or union type.
> 
> If you want it to do something that A, B, and C all support, use a generic 
> and/or a protocol. In this case limiting the inputs to only those three types 
> is probably a design smell. The whole point of a shared interface is that it 
> only matters that the interface is properly implemented by a type, not what 
> that type is.
> 
> If you don't care about doing anything with the value, just make your 
> function generic: func(input: T).
> 
> Austin
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Union instead of Optional

[Austin Zheng via swift-evolution]

I like the justification of unions as lightweight restricted ad-hoc enums. 
Definitely agreed with you in that the compiler will have to do more work, and 
should be able to handle the implicit conversion without going bonkers.

Thanks!

Austin

> On May 16, 2016, at 3:35 AM, Haravikk  wrote:
> 
> 
>> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution 
>>  wrote:
>> 
>> If A, B, and C are not related via protocol or class inheritance, then there 
>> is almost nothing you can do with value. Otherwise you still need to test 
>> against the concrete type using a case statement or a if-else ladder.
> 
> I think that a case statement or similar syntax will still be needed, and the 
> case names would just be the types themselves. This would work best with 
> support for type-narrowing, for example:
> 
>   func someMethod(value:(A|B|C)) {
>   switch (value) {
>   case .A:
>   value.someMethodForTypeA()
>   case .B:
>   value.someMethodForTypeB()
>   case .C:
>   value.someMethodForTypeC()
>   }
>   }
> 
> A union should really just be though of as a lightweight, restricted form of 
> enum that can be declared in a quick ad-hoc fashion, similar to how tuples 
> are a simpler form of struct.
> 
> I’m generally a +1 for the feature, but I’d be interested to hear about how 
> well equipped the compiler is for optimising something like this. In most 
> cases an Optional covers what I need, and in more complex cases I’d probably 
> declare overloads for each type (i.e- someMethod(value:A), 
> someMethod(value:B) etc.); unions could make the latter case simpler, but 
> will the compiler produce the same code behind the scenes, i.e- by isolating 
> what’s unique to each type?

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Union instead of Optional

[Austin Zheng via swift-evolution]

I'm sorry, but I don't understand the point you are trying to make.

If you pass in a value of type (A | B | C) to a function, what might you want 
to do with that value?

If you want to do one thing if the value is type A, something else if the value 
is type B, and something else if the value is type C, then you need to switch 
or otherwise type check the value at runtime. You can't get around this, no 
matter whether you use enums, protocols, generics, or union type.

If you want it to do something that A, B, and C all support, use a generic 
and/or a protocol. In this case limiting the inputs to only those three types 
is probably a design smell. The whole point of a shared interface is that it 
only matters that the interface is properly implemented by a type, not what 
that type is.

If you don't care about doing anything with the value, just make your function 
generic: func(input: T).

Austin


> On May 16, 2016, at 3:29 AM, Cao Jiannan  wrote:
> 
> 
> 
> Consider this case:
> 
> class A {
> var someCommonProperty: Int = 0
> }
> class B {
> var someCommonProperty: Int = 0
> }
> class C {
> var someCommonProperty: Int = 0
> }
> 
> protocol UnionABC {
> var someCommonProperty: Int
> }
> 
> extension A: UnionABC {}
> extension B: UnionABC {}
> extension C: UnionABC {}
> 
> 
> = If we using protocol
> 
> 
> func input(value: UnionABC) {
> print(value.someCommonProperty) // Compiler will know their common 
> properties automatically.
> if value is A {
> 
> } else if value is B {
> 
> } else if value is C {
> 
> } else {
> // There are other cases? Compiler doesn't know
> }
> }
> 
> let a = A()
> input(a)
> 
> = If we using union
> 
> func input(value: (A | B | C)) {
> print(value.someCommonProperty) // Compiler will know their common 
> properties automatically.
> 
> if value is A {
> 
> } else if value is B {
> 
> } else if value is C {
> 
> } else {
> // There no other cases, so the compiler trigger a warning.
> }
> }
> 
> let a = A()
> input(a)
> 
> 
> =
> 
> If using generic enum,
> the compiler doesn’t know the type relation between generic union with 
> original type.
> class A and UnionOf3 are totally two different types, has no 
> relationship.
> But class A and (A | B | C) keeps a relationship.
> 
> If using union, these two cases will be allowed:
> 
> let a = A()
> let union: (A|B|C) = a // Automatically wrap.
> 
> a == union // Can be compared, Yes
> 
> sub-typing: 
> 
> var fn0: A->Void = {print(v0)}
> var fn1: (A|B)->Void = {print(v0)}
> 
> fn0 = fn1 // Original Type and Union Type has a sub-typing relationship, OK
> 
> var fn2: (A|B|C)->Void = {print($0)}
> 
> fn0 = fn2 // OK
> fn1 = fn2 // OK
> 
> 
>> 在 2016年5月16日，18:17，Austin Zheng > > 写道：
>> 
>> This doesn't explain how I can use 'value' once an A() is passed into the 
>> function:
>> 
>> func input(value: (A | B | C)) {
>> 
>> }
>> 
>> If A, B, and C are not related via protocol or class inheritance, then there 
>> is almost nothing you can do with value. Otherwise you still need to test 
>> against the concrete type using a case statement or a if-else ladder.
>> 
>> The other 'gain' is being able to call 'input(A())', rather than 
>> 'input(.caseA(A()))'. I agree that the first form is prettier than the 
>> second one. I also think you could make the language pervasively prettier 
>> and more expressive by allowing for all sorts of implicit conversions. At 
>> some point clarity at the point of use beats conciseness, especially when 
>> code within a complex codebase needs to be maintained.
>> 
>> I understand that this is largely a matter of style - different people value 
>> different things, and that's wonderful. I welcome a formal proposal 
>> submitted to the swift-evolution process, and if one appears I'm happy to 
>> consider it in more detail and argue for or against it based on that.
>> 
>> Austin
>> 
>> 
>> 
>> On Sun, May 15, 2016 at 3:34 AM, Cao Jiannan > > wrote:
>> for example, there is a method input union of 3 types: A, B, C,
>> 
>> This is the three class.
>> 
>> class A {}
>> 
>> class B {}
>> 
>> class C {}
>> 
>> This is how it implemented under Swift 2:
>> 
>> enum UnionABC {
>> case classA(A)
>> case classB(B)
>> case classC(C)
>> }
>> 
>> func input(value: UnionABC) {
>> 
>> }
>> 
>> let a = A()
>> let b = B()
>> let c = C()
>> input(UnionABC.classA(a))
>> 
>> 
>> It needs announce all the cases and name each cases and cannot use class 
>> names as their case names.
>> 
>> what about using union? It is more easy and rational.
>> 
>> 
>> func input(value: (A | B | C)) {
>> 
>> }
>> 
>> let a= A()
>> input(a)
>> 
>> Or you can implement it with protocol and extension, but compiler will 

Re: [swift-evolution] Union instead of Optional

[Haravikk via swift-evolution]

> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution 
>  wrote:
> 
> If A, B, and C are not related via protocol or class inheritance, then there 
> is almost nothing you can do with value. Otherwise you still need to test 
> against the concrete type using a case statement or a if-else ladder.

I think that a case statement or similar syntax will still be needed, and the 
case names would just be the types themselves. This would work best with 
support for type-narrowing, for example:

func someMethod(value:(A|B|C)) {
switch (value) {
case .A:
value.someMethodForTypeA()
case .B:
value.someMethodForTypeB()
case .C:
value.someMethodForTypeC()
}
}

A union should really just be though of as a lightweight, restricted form of 
enum that can be declared in a quick ad-hoc fashion, similar to how tuples are 
a simpler form of struct.

I’m generally a +1 for the feature, but I’d be interested to hear about how 
well equipped the compiler is for optimising something like this. In most cases 
an Optional covers what I need, and in more complex cases I’d probably declare 
overloads for each type (i.e- someMethod(value:A), someMethod(value:B) etc.); 
unions could make the latter case simpler, but will the compiler produce the 
same code behind the scenes, i.e- by isolating what’s unique to each type?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Union instead of Optional

[Cao Jiannan via swift-evolution]

Consider this case:

class A {
var someCommonProperty: Int = 0
}
class B {
var someCommonProperty: Int = 0
}
class C {
var someCommonProperty: Int = 0
}

protocol UnionABC {
var someCommonProperty: Int
}

extension A: UnionABC {}
extension B: UnionABC {}
extension C: UnionABC {}


= If we using protocol


func input(value: UnionABC) {
print(value.someCommonProperty) // Compiler will know their common 
properties automatically.
if value is A {

} else if value is B {

} else if value is C {

} else {
// There are other cases? Compiler doesn't know
}
}

let a = A()
input(a)

= If we using union

func input(value: (A | B | C)) {
print(value.someCommonProperty) // Compiler will know their common 
properties automatically.

if value is A {

} else if value is B {

} else if value is C {

} else {
// There no other cases, so the compiler trigger a warning.
}
}

let a = A()
input(a)


=

If using generic enum,
the compiler doesn’t know the type relation between generic union with original 
type.
class A and UnionOf3 are totally two different types, has no 
relationship.
But class A and (A | B | C) keeps a relationship.

If using union, these two cases will be allowed:

let a = A()
let union: (A|B|C) = a // Automatically wrap.

a == union // Can be compared, Yes

sub-typing: 

var fn0: A->Void = {print(v0)}
var fn1: (A|B)->Void = {print(v0)}

fn0 = fn1 // Original Type and Union Type has a sub-typing relationship, OK

var fn2: (A|B|C)->Void = {print($0)}

fn0 = fn2 // OK
fn1 = fn2 // OK


> 在 2016年5月16日，18:17，Austin Zheng  写道：
> 
> This doesn't explain how I can use 'value' once an A() is passed into the 
> function:
> 
> func input(value: (A | B | C)) {
> 
> }
> 
> If A, B, and C are not related via protocol or class inheritance, then there 
> is almost nothing you can do with value. Otherwise you still need to test 
> against the concrete type using a case statement or a if-else ladder.
> 
> The other 'gain' is being able to call 'input(A())', rather than 
> 'input(.caseA(A()))'. I agree that the first form is prettier than the second 
> one. I also think you could make the language pervasively prettier and more 
> expressive by allowing for all sorts of implicit conversions. At some point 
> clarity at the point of use beats conciseness, especially when code within a 
> complex codebase needs to be maintained.
> 
> I understand that this is largely a matter of style - different people value 
> different things, and that's wonderful. I welcome a formal proposal submitted 
> to the swift-evolution process, and if one appears I'm happy to consider it 
> in more detail and argue for or against it based on that.
> 
> Austin
> 
> 
> 
> On Sun, May 15, 2016 at 3:34 AM, Cao Jiannan  > wrote:
> for example, there is a method input union of 3 types: A, B, C,
> 
> This is the three class.
> 
> class A {}
> 
> class B {}
> 
> class C {}
> 
> This is how it implemented under Swift 2:
> 
> enum UnionABC {
> case classA(A)
> case classB(B)
> case classC(C)
> }
> 
> func input(value: UnionABC) {
> 
> }
> 
> let a = A()
> let b = B()
> let c = C()
> input(UnionABC.classA(a))
> 
> 
> It needs announce all the cases and name each cases and cannot use class 
> names as their case names.
> 
> what about using union? It is more easy and rational.
> 
> 
> func input(value: (A | B | C)) {
> 
> }
> 
> let a= A()
> input(a)
> 
> Or you can implement it with protocol and extension, but compiler will not 
> know how many cases it should have.
> 
> 
> protocol UnionABC {
> 
> }
> 
> extension A: UnionABC {}
> extension B: UnionABC {}
> extension C: UnionABC {}
> 
> 
> func input(value: UnionABC) {
> if value is A {
> 
> } else if value is B {
> 
> } else if value is C {
> 
> } else {
> // There are other cases? Compiler doesn't know
> }
> }
> 
> let a = A()
> input(a)
> 
> 
> 
>> 下面是被转发的邮件：
>> 
>> 发件人: frog...@163.com 
>> 主题: 回复： [swift-evolution] Union instead of Optional
>> 日期: 2016年5月15日 GMT+8 18:00:55
>> 收件人: Austin Zheng >
>> 
>> 
>> Enum and Union are two things.
>> 
>> If you use Enum to implement Union, you should announce it with case name.
>> 
>> Another issue using enum instead of union is that,  union can combine types 
>> as many as possible, you just write ( A | B | C ... | Z), but for enum, you 
>> should carefully announce it for each case. 
>> 
>> 在 2016年5月15日，15:22，Austin Zheng > > 写道：
>> 
>>> In addition, not everything in Swift can be modeled in terms of inheritance 
>>> relationships.
>>> 
>>> I'm a little curious as to why union types keep on coming 

Re: [swift-evolution] Union instead of Optional

[Austin Zheng via swift-evolution]

This doesn't explain how I can use 'value' once an A() is passed into the
function:

func input(value: (A | B | C)) {


}

If A, B, and C are not related via protocol or class inheritance, then
there is almost nothing you can do with value. Otherwise you still need to
test against the concrete type using a case statement or a if-else ladder.

The other 'gain' is being able to call 'input(A())', rather than
'input(.caseA(A()))'. I agree that the first form is prettier than the
second one. I also think you could make the language pervasively prettier
and more expressive by allowing for all sorts of implicit conversions. At
some point clarity at the point of use beats conciseness, especially when
code within a complex codebase needs to be maintained.

I understand that this is largely a matter of style - different people
value different things, and that's wonderful. I welcome a formal proposal
submitted to the swift-evolution process, and if one appears I'm happy to
consider it in more detail and argue for or against it based on that.

Austin



On Sun, May 15, 2016 at 3:34 AM, Cao Jiannan  wrote:

> for example, there is a method input union of 3 types: A, B, C,
>
> This is the three class.
>
> class A {}
>
> class B {}
>
> class C {}
>
> This is how it implemented under Swift 2:
>
> enum UnionABC {
> case classA(A)
> case classB(B)
> case classC(C)
> }
>
> func input(value: UnionABC) {
>
>
> }
>
> let a = A()
> let b = B()
> let c = C()
> input(UnionABC.classA(a))
>
>
> It needs announce all the cases and name each cases and cannot use class
> names as their case names.
>
> what about using union? It is more easy and rational.
>
>
> func input(value: (A | B | C)) {
>
>
> }
>
> let a= A()
> input(a)
>
> Or you can implement it with protocol and extension, but compiler will not
> know how many cases it should have.
>
>
> protocol UnionABC {
>
>
> }
>
> extension A: UnionABC {}
> extension B: UnionABC {}
> extension C: UnionABC {}
>
>
> func input(value: UnionABC) {
> if value is A {
>
>
> } else if value is B {
>
>
> } else if value is C {
>
>
> } else {
> // There are other cases? Compiler doesn't know
> }
> }
>
> let a = A()
> input(a)
>
>
>
> 下面是被转发的邮件：
>
> *发件人: *frog...@163.com
> *主题: **回复： [swift-evolution] Union instead of Optional*
> *日期: *2016年5月15日 GMT+8 18:00:55
> *收件人: *Austin Zheng 
>
>
> Enum and Union are two things.
>
> If you use Enum to implement Union, you should announce it with case name.
>
> Another issue using enum instead of union is that,  union can combine
> types as many as possible, you just write ( A | B | C ... | Z), but for
> enum, you should carefully announce it for each case.
>
> 在 2016年5月15日，15:22，Austin Zheng  写道：
>
> In addition, not everything in Swift can be modeled in terms of
> inheritance relationships.
>
> I'm a little curious as to why union types keep on coming up, when enums
> can do everything they can and much more (methods, constraints on generic
> types, conformance to protocols).
>
> Austin
>
> 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

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Tyler Fleming Cloutier via swift-evolution]

> On May 16, 2016, at 2:16 AM, Dave Abrahams  wrote:
> 
> 
> on Mon May 16 2016, Tyler Fleming Cloutier  wrote:
> 
 Super interesting talk! 
 
 But consider: isn't a single value type able to represent *multiple*
 ethereal types?
>>> 
>>> “ethereal?”  Does he really use that term?  I don't know what it means.
>> 
>> He does pretty frequently. He also refers to them as Mathematical
>> Types. He means the logical type that the C++ implementation is
>> supposed to approximate.
> 
> OK.
> 
>> An example he gives is int and how it only approximates the logical
>> Integer type, because it is represented in many ways, e.g. short, int,
>> long, long long. None of them are exactly the same the logical type.
> 
> Check.
> 
 std::vector is a good example. What are the salient attributes of this
 type? In the talk John says that
 
 1. the size is
 2. the values in the vector are
 3. the capacity, however *is not*
>>> 
>>> Yup, just like Array.  Thus the equality test for arrays ignores
>>> capacity.
>>> 
 in which case std::vector would be an approximation of an ethereal
 type which has a list of values, and the capacity is just an artifact
 of the approximation. But you could also imagine an ethereal type
 which *does* depend of the capacity of the object, and std::vector
 unwittingly approximates that type too! 
 In this case someone, unfamiliar with the implementation might use
 it under the assumption that capacity *is* part of the ethereal type
 and by extension the equality of std::vector.
 
 John avoids the problem by saying that this must specified in the
 documentation.
>>> 
>>> Yes.
>>> 
 I tend to see this as breaking encapsulation since you need to know
 the implementation of the equality operator to be able to determine if
 a public property, the capacity, is part of the ethereal type. 
>>> 
>>> No, you just need documentation.
>>> 
 It’s not always the case that you have access to either the
 documentation or the implementation.
>>> 
>>> Without the documentation, you're lost.  We go a lot further with naming
>>> conventions in Swift than typical C++ does, but even in Swift you can't
>>> expect to fully understand semantics without documentation.
>> 
>> Swift also goes a lot further with enforcing things like immutability
>> by default with let, particularly for value types. I think that with
>> well defined rules you can go further with what’s enforced, and remove
>> the need for documentation, especially since the distinctions with
>> regards to value types can be subtle.
> 
> Remove the need for documentation! Good luck with that, my friend.
> 
 This implies, therefore, that if salient attributes *define* the
 immutability of the value type, then the public interface is not
 guaranteed to be immutable, since it is allowed to include non-salient
 attributes. For example, a vector’s capacity could change at any time,
 by virtue of it being stored via a reference.
 
 What I am saying is that a PureValue is a value type whose public
 interface comprises *only* salient attributes. And I also claim that
 this is a useful distinction amongst value types.
>>> 
>>> Then Array is not a PureValue because it exposes capacity?!  That
>>> sounds crazy to me, since the Array's capacity in no sense has reference
>>> semantics.
>> 
>> I would argue, rather, that capacity for Array *is* a salient
>> attribute, by virtue being public 
> 
> Then you're missing the point.  There would be no point in making the
> distinction “salient” if all public API were salient.  Lakos only
> considers public API.

I’m certainly not missing the point. He is saying that not all public API is 
“salient” because it doesn’t pertain to the logical or ethereal type. I’m 
saying that not everybody will agree on what the ethereal type is, thus they 
will not agree on what is salient.

One what to eliminate the possibility of disagreement is do define the ethereal 
type as what is presented as public API, thus the entire public API is salient. 
No more need for the “salient” distinction, that all goes away.

Whether or not you think this is a good idea is another thing entirely.

> 
>> and that Array is a PureValue by virtue of it not having
>> reference semantics. This I propose is valid, because even though it’s
>> not the most intuitive in this case, it is possible that some
>> algorithm interprets capacity to be salient and relies on two arrays
>> with different capacities being not equal.
>> 
>> I can certainly understand the opposing argument here, but at least
>> this way it is unambiguous.
> 
> Capacity, in Lakos' terms, is non-salient, and that's unambiguous.
> 

“In Lakos’ terms”

I don’t think many people are familiar with Lakos’ terms, and thus it is quite 
ambiguous, that’s kinda my point. What is salient to you is not necessarily 
what is salient to me.

I’m suggesting 

Re: [swift-evolution] Union instead of Optional

[Austin Zheng via swift-evolution]

Precisely. To me unions are to enums with associated type the same way tuples 
are to structs. One is named, has well-defined semantics, can conform to 
protocols, can have complex internal structure, can have methods, etc. The 
other is ad-hoc and lightweight, easy to define at the site of use, best suited 
for simple purposes, has special syntax to support it. 

Even if we can extend tuples in the future, though, I wouldn't want structs to 
go away. When exceeding some level of complexity structs are just more explicit 
than tuples, and therefore easier to understand.

Finally, please note that Ceylon is a pervasively object-oriented language with 
a single root superclass. Neither of those is true for Swift, which chooses to 
solve a lot of problems in a different (and I would argue, superior) way. So 
solutions that might work well in Ceylon might not be suited for Swift, at 
least not without modification, and vice versa. The core team could certainly 
have chosen to model Swift's type system after that of e.g. Scala, but they 
chose not to, and I think they did so for good reason.

Austin


> On May 16, 2016, at 2:58 AM, Thorsten Seitz  wrote:
> 
> Yes, enums are like explicit named type unions whereas ad hoc type unions can 
> be useful exactly because they are ad hoc.
> It is kind of like named functions vs. anonymous functions. Both have their 
> place.
> 
> Ceylon makes tremendous use of union and intersection types. While they don’t 
> have enums in the Swift sense they have something very similar, so they 
> certainly make use of both approaches, too. Like I said both have their place 
> and introducing type unions shouldn’t replace enums (unless we should 
> discover that type unions can do all that enums do, e.g. with extensions it 
> might even be possible to add methods to type unions in Swift).
> 
> -Thorsten
> 
> 
>> Am 15.05.2016 um 13:07 schrieb Tino Heth via swift-evolution 
>> >:
>> 
>> I don't know if there has been any internal discussion about using 
>> union-types instead of enums, but afaics, there are no obvious downsides for 
>> that approach.
>> 
>>> I'm a little curious as to why union types keep on coming up, when enums 
>>> can do everything they can and much more (methods, constraints on generic 
>>> types, conformance to protocols).
>> Are there any strong reasons why those features would not be possible with 
>> union types?
>> 
>> There has been a discussion started because it is a little bit cumbersome to 
>> create enum-properties (and methods).
>> With unions, there would be no need for all those switch-statements, and 
>> would be possible to configure cases in a central location.
>> There has also been a proposal for "anonymous enums", which could be modeled 
>> with unions in a very elegant way.
>> ___
>> 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

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

I’ve rewritten my proposal towards the Generic Manifesto for Swift 3. I’ve 
polished a lot of thoughts to make everything as clear as possible. I still 
have to write Motivation and Proposed solution, but everything else seems to be 
rock solid - I’d say.

Again `All<>` should not intersect but merge and infer types if possible. There 
is no need for inheritance branches inside angle brackets (only possible with 
classes anyway).

Here is the new url: 
https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/-mechanism-to-combine-types-and-protocols.md

Future direction might be promising as well. :)

-- 
Adrian Zubarev
Sent with Airmail___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Austin Zheng via swift-evolution]

+1. Non-type generic parameters can be handled if/when they are proposed after 
Swift 3. There have to be better ways to encourage proper organization of the 
elements of a method header than forcing a redundant and non-obvious 
conformance to 'Any'; if this is mandatory the proposal is fatally flawed and 
should be taken back to the drawing board.

Austin

> On May 16, 2016, at 2:36 AM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> Having to declare conformance to `Any` is just noise and should *not* be 
> mandatory IMHO.
> 
> -Thorsten
> 
> 
>> Am 16.05.2016 um 07:59 schrieb Pyry Jahkola via swift-evolution 
>> >:
>> 
>> 
>>> On 16 May 2016, at 01:45, Brent Royal-Gordon via swift-evolution 
>>> > wrote:
>>> 
>>> I'm actually tempted to suggest that a conformance should be *mandatory* 
>>> and you should have to specify `Any` if you don't have anything more 
>>> specific to say about the generic parameter:
>>> 
>>> func map(@noescape transform: (Element) throws -> T) rethrows 
>>> -> [T]
>> 
>> That's a good idea indeed if we ever intend to have other kinds of generic 
>> arguments (in particular, constant values like `length: Int`).
>> 
>> Even so, I wouldn't want to prohibit adding more protocol constraints in the 
>> where clause even if you can introduce all constaints of `T` at once as `T: 
>> protocol`.
>> 
>> — Pyry
>> 
>> ___
>> 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

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Thorsten Seitz via swift-evolution]

Having to declare conformance to `Any` is just noise and should *not* be 
mandatory IMHO.

-Thorsten


> Am 16.05.2016 um 07:59 schrieb Pyry Jahkola via swift-evolution 
> :
> 
> 
>> On 16 May 2016, at 01:45, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> 
>> I'm actually tempted to suggest that a conformance should be *mandatory* and 
>> you should have to specify `Any` if you don't have anything more specific to 
>> say about the generic parameter:
>> 
>>  func map(@noescape transform: (Element) throws -> T) rethrows 
>> -> [T]
> 
> That's a good idea indeed if we ever intend to have other kinds of generic 
> arguments (in particular, constant values like `length: Int`).
> 
> Even so, I wouldn't want to prohibit adding more protocol constraints in the 
> where clause even if you can introduce all constaints of `T` at once as `T: 
> protocol`.
> 
> — Pyry
> 
> ___
> 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

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Dave Abrahams via swift-evolution]

on Mon May 16 2016, Tyler Fleming Cloutier  wrote:

>>> Super interesting talk! 
>>> 
>>> But consider: isn't a single value type able to represent *multiple*
>>> ethereal types?
>> 
>> “ethereal?”  Does he really use that term?  I don't know what it means.
>
> He does pretty frequently. He also refers to them as Mathematical
> Types. He means the logical type that the C++ implementation is
> supposed to approximate.

OK.

> An example he gives is int and how it only approximates the logical
> Integer type, because it is represented in many ways, e.g. short, int,
> long, long long. None of them are exactly the same the logical type.

Check.

>>> std::vector is a good example. What are the salient attributes of this
>>> type? In the talk John says that
>>> 
>>> 1. the size is
>>> 2. the values in the vector are
>>> 3. the capacity, however *is not*
>> 
>> Yup, just like Array.  Thus the equality test for arrays ignores
>> capacity.
>> 
>>> in which case std::vector would be an approximation of an ethereal
>>> type which has a list of values, and the capacity is just an artifact
>>> of the approximation. But you could also imagine an ethereal type
>>> which *does* depend of the capacity of the object, and std::vector
>>> unwittingly approximates that type too! 
>>> In this case someone, unfamiliar with the implementation might use
>>> it under the assumption that capacity *is* part of the ethereal type
>>> and by extension the equality of std::vector.
>>> 
>>> John avoids the problem by saying that this must specified in the
>>> documentation.
>> 
>> Yes.
>> 
>>> I tend to see this as breaking encapsulation since you need to know
>>> the implementation of the equality operator to be able to determine if
>>> a public property, the capacity, is part of the ethereal type. 
>> 
>> No, you just need documentation.
>> 
>>> It’s not always the case that you have access to either the
>>> documentation or the implementation.
>> 
>> Without the documentation, you're lost.  We go a lot further with naming
>> conventions in Swift than typical C++ does, but even in Swift you can't
>> expect to fully understand semantics without documentation.
>
> Swift also goes a lot further with enforcing things like immutability
> by default with let, particularly for value types. I think that with
> well defined rules you can go further with what’s enforced, and remove
> the need for documentation, especially since the distinctions with
> regards to value types can be subtle.

Remove the need for documentation! Good luck with that, my friend.

>>> This implies, therefore, that if salient attributes *define* the
>>> immutability of the value type, then the public interface is not
>>> guaranteed to be immutable, since it is allowed to include non-salient
>>> attributes. For example, a vector’s capacity could change at any time,
>>> by virtue of it being stored via a reference.
>>> 
>>> What I am saying is that a PureValue is a value type whose public
>>> interface comprises *only* salient attributes. And I also claim that
>>> this is a useful distinction amongst value types.
>> 
>> Then Array is not a PureValue because it exposes capacity?!  That
>> sounds crazy to me, since the Array's capacity in no sense has reference
>> semantics.
>
> I would argue, rather, that capacity for Array *is* a salient
> attribute, by virtue being public 

Then you're missing the point.  There would be no point in making the
distinction “salient” if all public API were salient.  Lakos only
considers public API.

> and that Array is a PureValue by virtue of it not having
> reference semantics. This I propose is valid, because even though it’s
> not the most intuitive in this case, it is possible that some
> algorithm interprets capacity to be salient and relies on two arrays
> with different capacities being not equal.
>
> I can certainly understand the opposing argument here, but at least
> this way it is unambiguous.

Capacity, in Lakos' terms, is non-salient, and that's unambiguous.

>>> John also says that a salient attribute must derive *only* from the
>>> state of a particular instance of a type. This by extension implies
>>> that a salient attribute must derive exclusively from pure
>>> values. However, this also means that without some “indirect” keyword,
>>> PureValues are restricted to acyclic and non-recursive structures.
>>> 
>>> I also claim that equality can be automatically generated for
>>> PureValues by equating each of there salient attributes.
>> 
>> That's true for almost any value, provided we define equality for
>> reference types properly.
>> 
>>> I really apologize if this seems like rambling again, but I am very
>>> interested in this problem.
>> 
>> I'm glad you are! Few programmers dig far enough to understand value
>> semantics at a deep level.
>> 
>> All that said, I still think PureValue is a red herring.  Unless I'm
>> forgetting something that happened in the thread two weeks ago, nobody
>> has shown me code that relies on 

[swift-evolution] [Idea] "guard not let" optional binding

[John Morgan via swift-evolution]

I've occasionally hit this problem too, but I don’t think it warrants a
language addition, as it can be overcome in other ways. I would move the
expensive calculation into its own private method and rewrite your example
like this:

return cachedValue ?? calculatedValue()

In my opinion that would fit better with the single responsibility
principle and make unit testing easier.

John

> -1 as there IMO some confusion between all these `not` and `else` and the
> meaning of the expression at all is not obvious for me: "check that not
> allowed to assign _someExpensiveResult to some instance cachedValue,
> otherwise return something"
>
> This really looks nice, clean and obvious :
>
> guard cachedValue == nil else {
> // here you need just to fast return unwrapped value of cachedValue
> // so, IMO unwrapping it in this block is OK
> return cachedValue!
> }
> // here you want to have cachedValue == nil, so you'll need to unwrap
> it(after assignment) in any case.
>
> What I can see as improvement in this direction, something like this:
> guard cachedValue == nil else let cachedValue! {
> // here you can use unwrapped cachedValue
> return cachedValue
> }
>
>
> Hmm... Btw, what about improving in optional binding: It is common to
> shadow optional value name with unwrapped value with same name:
>
> if let value = value {...} // too much noise
>
> What about introduce such syntax:
>
> if let value! {
> // unwrapped value here
> }
>
> Seems like clear and obvious about what does this mean. Opinions? (before
I
> drop this to separate thread)
>
>
> On 14.05.2016 8:52, Karl via swift-evolution wrote:
> > If we want to check that an optional has a value and bail if it
doesn't, we have the helpful pattern:
> >
> > guard let x = x else { throw SomeError }
> >
> > However, it is also fairly common that you want to check that an
optional *is* nil, and still bail if it isn’t (maybe using the value that
you now know exists), e.g:
> >
> > guard cachedValue == nil else { return cachedValue! }
> > cachedValue = //… expensive calculation
> >
> > It seems a little bit “unfair” that we have this lovely clean `let`
syntax when checking for Optional.Some, but we to have to do this ugly
manual check against nil and explicit unwrap when checking for
Optional.None. There is literally no other way to satisfy the guard
statement; our optional bindings only go one-way can’t be evaluated.
> >
> > What about if we introduced a “not” modifier to optional bindings?
> >
> > guard not let cachedValue = _someExpensiveResult else { return
cachedValue }
> >
> > This obviously wouldn’t make sense for “if let…” switching, as the
variables get bound in the ‘else’ block and the code wouldn’t be very
readable. For the special case of a guard statement, though, which only has
an ‘else’ block, it does make some sense.
> >
> > If we had something like this, certainly in my code, I’d be able to
eliminate almost all (maybe even all) remaining force-unwraps of optionals;
that’s great! It’d be amazing if the language was expressive enough that
you could go without ever having to force-unwrap an optional. And it just
makes sense.
> >
> > Thoughts?
> >
> > Karl
> > ___
> > swift-evolution mailing list
> > swift-evolution at 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

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Pyry Jahkola via swift-evolution]

> On 16 May 2016, Thorsten Seitz wrote:
> 
> Funny, for me reading a function is quite the other way around:
> I prefer to first look at the function name and parameter list to give me an 
> idea of what the function will do (the parameter names help a lot).
> Having instead first to memorize a list of types with all their constraints 
> just builds up the cognitive load without helping much, because their usage 
> is yet unknown.

This is also my biggest motivation for the proposal: keeping the function name 
and arguments close to each other.

> So, for me reading the signature would look like (with the proposal in place):
> 
>>> internal func _arrayOutOfPlaceReplace(_ source: inout B, _ bounds: 
>>> Range, _ newValues: C, _ insertCount: Int)


^ Agreed! That's essentially what I'm trying to find too when skimming through 
code.

An alternative approach with the same desired outcome would be moving the 
parameter list before the function name, either `func<...> someFunction(...)`, 
or even before the `func` keyword. But since we already use `where`, it seems 
more natural to me for Swift to place the constraints list to the end.

— Pyry

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Thorsten Seitz via swift-evolution]

Funny, for me reading a function is quite the other way around:
I prefer to first look at the function name and parameter list to give me an 
idea of what the function will do (the parameter names help a lot).
Having instead first to memorize a list of types with all their constraints 
just builds up the cognitive load without helping much, because their usage is 
yet unknown.

So, for me reading the signature would look like (with the proposal in place):

>> internal func _arrayOutOfPlaceReplace(_ source: inout B, _ bounds: 
>> Range, _ newValues: C, _ insertCount: Int)

Ah, this function does some replacement within a source which is mutated. The 
replacement seems to affect a range within the source and there are some new 
values given together with their count.
Now I have already a feeling what the method does and can look at the types to 
get more details.

If I would have to read the types first I would not have been able to extract 
as much information from them to guess what the function does, so trying to 
interpret them would just have been a waste of time and I would have to look 
them up again after reading the parameter list anyway.

-Thorsten



> Am 15.05.2016 um 12:38 schrieb Nicola Salmoria via swift-evolution 
> :
> 
> David Hart via swift-evolution  writes:
> 
>> 
>> 
>> Hi Karl,
>> 
>> As author of this proposal, the one about constraints on associated types,
> and the one on type-aliases in protocols (all from the Generics Manifesto -
> original authorship to Douglas Gregor) I’d like to provide additional
> reasoning behind my wish to push this proposal through, as a whole.
>> 
>> First of all, there is a personal preference. I’ve used C# for many many
> years, which has its where clause at the end of the declaration (like this
> proposal), and I’ve used Swift since its unveiling. The experience with
> using both styles for several years makes me favour this proposal’s syntax
> because I find it much easier to read and format for readability.
>> 
>> Constraints on associated type will provide more expressivity but I doubt
> it will greatly reduce protocol constraint clauses in a majority of cases.
> And yes, type-aliases in protocols will shorten clauses, but I still think
> they will more readable with the where clause at the end.
>> 
>> For example, here is a method I took (as-is) from the Standard Library
> which has a few constraints, and which I further simplified if we imagine
> that Sequence has an Element typealias for Iterator.Element:
>> 
>> 
>> internal func _arrayOutOfPlaceReplace<
>>   B : _ArrayBufferProtocol, C : Collection
>>   where  C.Element == B.Element,
>>   B.Index == Int
>>> (  _ source: inout B, _ bounds: Range, _ newValues:
>> C, _ insertCount: Int) {
>> 
>> See how the Standard Library authors formatted it for readability and how
> as a consequence arguments which use the generic types are further apart
> from the declaration of those generic types. But with this proposal, the
> declaration might be formatted to:
>> 
>> internal func _arrayOutOfPlaceReplace(_ source: inout B,
>>  _ bounds: Range, _ newValues: C, _ insertCount: Int)
>>   where
>> B : _ArrayBufferProtocol,
>>   C : Collection,
>>   C.Iterator.Element == B.Element,
>>   B.Index == Int
>> {
>> 
>> Do you need believe this is now more readable?
>> 
>> David.
> 
> Thanks for the real world example!
> 
> I think that the second arguably *looks* better. But is it more *readable*?
> Not for me.
> 
> Let me try to do a brain dump while I mentally parse the declaration.
> 
>> internal func _arrayOutOfPlaceReplace(
> 
> Mmm, here we have a function that has something to do with arrays, generic
> on two types. Maybe it will take an Array and output an Array?
> 
>> _ source: inout B,
> 
> Ah, the first argument is a B that will be changed. Maybe the function deals
> with Array and will replace occurrences of 'source' with something else?
> 
>> _ bounds: Range,
> 
> Ok, this surely must be the range of the Array to operate on.
> 
>> _ newValues: C,
> 
> Oh, this parameter is called 'newValues', so C can't be a single value. It
> must be a Collection, surely.
> 
>> _ insertCount: Int)
> 
> ... I can't figure out what this could be.
> 
>> where
>> B : _ArrayBufferProtocol,
> 
> Oh, B was some kind of buffer. OK so the function probably takes this
> buffer, and replaces 'range' with 'newValues'
> 
>> C : Collection,
>> C.Iterator.Element == B.Element,
> 
> Good, this confirms what I thought.
> 
>> B.Index == Int
> 
> Looks like an implementation detail, I guess that's why 'range' is a
> Range and 'insertCount' is an Int. Presumably the function needs to do
> some operations that the generic Index doesn't guarantee.
> 
> So that's the end of it. I have a vague idea of what the function might do,
> and had to revise my expectations a few times while reading its declaration.
> 
> 
> Let's try again with the original declaration.
> 
>> internal func 

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Thorsten Seitz via swift-evolution]

> Am 14.05.2016 um 20:19 schrieb Tony Allevato via swift-evolution 
> :
> 
> On 2016-05-14 16:29:40 +, Haravikk via swift-evolution said:
> 
>> On 14 May 2016, at 16:52, Tony Allevato via swift-evolution 
>>  wrote:
>>> To me, this makes declarations with complex sets of constraints much harder 
>>> to read, because I have to hunt them down instead of finding them all in 
>>> one place. Under this proposal, the longer an argument list gets, the 
>>> further separated the constraints are from the type parameters that use 
>>> them.
>> This is partly an issue of how you use the feature rather than an issue with 
>> the feature itself, as you’re assuming that everything is all on one line, 
>> but really I think the intent of this feature is to better support 
>> multi-line declarations. It enables things like:
>>  func someMethod(value:S) -> AnySequence
>>  where S.Generator.Element == T { … }
> 
> I'm not assuming that. Under the current syntax, I would format your example 
> as:
> 
>   func someMethod<
>   S: SequenceType, T
>   where S.Generator.Element == T
>   >(value: S) -> AnySequence {
>   ...
>   }
> 
> which I find to be quite readable across multiple lines without scattering 
> the generic type information in two places across the function.

But this scatters the function definition itself, i.e. the name of the function 
and its parameter list and return type over multiple lines.
And splitting the <> over multiple lines is really ugly. The leading > even 
looks like an operator (is it func >(value: S) being defined?).

I think 

func someMethod(value: S) -> AnySequence
where S.Generator.Element == T {
…
}

is much more readable.

Or what about using some more suggestive names for the generic paramters, so 
that the core of the function definition can be kept even shorter without 
loosing readability:

func someMethod(value: Seq) -> AnySequence
where
Seq: SequenceType,
Seq.Generator.Element == Elem {
…
}

Here, I don’t see the need to keep all constraints up front because the generic 
parameters already suggest their nature. The where clause just fills in the 
technical constraints.

This would not be possible with the current syntax at all.

-Thorsten


> 
> 
>> The actual function signature stays on the top, but the constraint can now 
>> move down neatly, since it’s a supplementary condition that you may not to 
>> consider right away, or at all, if it’s just reinforcing some kind of 
>> common-sense limitation.
> 
> That's kind of a judgment call, though. Not all constraints fit that 
> mold—some encode very important information that it makes sense to keep up 
> front.
> 
> 
>> This is partly why I’d prefer to see it optional though, as some things will 
>> fit on one line reasonably well (you probably could with the above for 
>> example), but like you say, with it all on one line the return type becomes 
>> less visible.
> 
> No matter how you format the proposed syntax, the return type is sandwiched 
> in the middle of two things that describe generic type information—whether 
> it's on one line or not doesn't change that. I believe that harms 
> readability, especially if you have some constraints (conformance) on the 
> left and some (associated types) on the right.
> 
> I would be strongly opposed to making this optional—that adds complexity to 
> the language to support parsing two patterns, as well as the cognitive load 
> of someone reading Swift code, especially if written in the different style. 
> As was mentioned in another thread, "Swift is an opinionated languge", and I 
> hope we'd be prescriptive about syntactic constructs like this that are more 
> significant than "does the curly brace go on the same line or the next line". 
> (Even if the choice is one that I disagree with in the end, I'd rather there 
> be one way than multiple ways!)
> 
> 
>> ___
>> 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

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Thorsten Seitz via swift-evolution]

> Am 14.05.2016 um 17:52 schrieb Tony Allevato via swift-evolution 
> :
> 
> On 2016-05-10 18:51:29 +, Chris Lattner via swift-evolution said:
> 
>> Hello Swift community,
>> The review of "SE-0081: Move where clause to end of declaration" begins now 
>> and runs through May 16. The proposal is available here:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md
>>  Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> What goes into a review?
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to the direction of Swift. 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>>  * What is your evaluation of the proposal?
> 
> -1. My thoughts essentially mirror those of Jon Shier, Karl Wagner, and 
> Nicola Salmoria.
> 
> To me, this makes declarations with complex sets of constraints much harder 
> to read, because I have to hunt them down instead of finding them all in one 
> place. Under this proposal, the longer an argument list gets, the further 
> separated the constraints are from the type parameters that use them.
> 
> This solution also obfuscates function definitions. Having the function's 
> return type be the very last thing in the header line is has very nice 
> readability benefit, and this proposal takes that away by sandwiching the 
> return type awkwardly in the middle.

IMO the readability is improved because the where clause can be easily placed 
in a new line. Generic function definitions with where clauses typically are 
too long for being crammed into one line without having the readability suffer. 
The proposal allows a much more readable splitting of the definition into 
several lines. This completely alleviates the problem of separating generic 
type information or sandwiching the return type, because the where clause in 
the next line will be near the generic type parameter list again.
Taking Jon Shier’s example: 
The following definition is already too long IMO. The current syntax does not 
allow nice splitting of the line and readability suffers from the long gap 
between the function name and its parameter list:
func something(with something: T) -> 
String

instead of writing a long line with sandwiching problems like that:
func something(with something: T) -> String where T == 
T.DecodedType

I would write:
func something(with something: T) -> String 
where T == T.DecodedType


To recap: I think that readability improves with the proposal for the following 
reasons:
- The gap between the function name and its parameter list is reduced
- Definitions with where clauses typically are already too long to readably fit 
into one line, so they should be split over more than one line. The current 
syntax does not offer a natural position for a line break (breaking before the 
where even further increases the gap between the function name and its 
parameter list and it looks ugly because of the angle brackets being on 
separate lines.

-Thorsten

> 
> The admission that some constraints should be allowed inside the angle 
> brackets (conformance constraints) while moving others (associated type 
> constraints) out introduces inconsistency in the language and seems like an 
> incomplete fix. From a teaching point of view, I would find it more difficult 
> to explain to users of the language "constraints that look like *this* go 
> here, but constraints that look like *that* go way over there". The current 
> model of "all generic constraints go between < and >" is clean and simple.
> 
> Lastly, from a bit of a pedantic point of view, moving the where-clause to 
> the end of a function declaration makes it look like the function is 
> satisfying some constraints, when it's actually the generic type parameters 
> that are satisfying them. In that sense, it's better to keep them closer 
> together.
> 
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yes, but not in this fashion. I agree with some of the other sentiment that 
> there should be better ways of satisfying complex constraint sets (through 
> generic typealiases or something else) to clean them up, but moving the 
> where-clause creates more readability problems than it solves.
> 
>>  * Does this proposal fit well with the feel and direction of Swift?
> 
> I don't believe so; it adds inconsistency rather than removes it.
> 
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> No languages that allow generics to be expressed so richly as 

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On May 16, 2016, at 8:39 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
>> on Sun May 15 2016, Tyler Fleming Cloutier  wrote:
>> 
>>On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>>on Mon May 09 2016, Matthew Johnson  wrote:
>> 
>>On May 8, 2016, at 1:51 AM, Dave Abrahams  
>> wrote:
>> 
>>on Sat May 07 2016, Andrew Trick  wrote:
>> 
>>  On May 7, 2016, at 2:04 PM, Dave Abrahams 
>>  wrote:
>> 
>>  2. Value types are not "pure" values if any part of the 
>> aggregate
>>  contains a
>>  reference whose type does not have value semantics. 
>> 
>>  Then Array is not a “pure” value (the buffer contained 
>> in an
>>  Array is a mutable reference type that on its own, 
>> definitely does
>>  *not* have value semantics). I don't think this is what you 
>> intend, and
>>  it indicates that you need to keep working on your 
>> definition.
>> 
>>It sounds like you’re changing the definition of value 
>> semantics to make it
>>impossible to define PureValue. 
>> 
>>Not on purpose.
>> 
>>Does Array have value semantics then only if T also has 
>> value
>>semantics?
>> 
>>This is a great question; I had to rewrite my response four times.
>> 
>>In my world, an Array always has value semantics if you 
>> respect the
>>boundaries of element values as defined by ==.  That means that 
>> if T is
>>a mutable reference type, you're not looking through references, 
>> because
>>== is equivalent to ===.
>> 
>>Therefore, for almost any interesting SomeConstraint that doesn't 
>> refine
>>ValueSemantics, then
>> 
>>Array
>> 
>>only has value semantics if T has value semantics, since 
>> SomeConstraint
>>presumably uses aspects of T other than reference identity.  
>> 
>>The claim has been made that Array always has value semantics,
>>implying that the array value’s boundary ends at the boundary 
>> of it’s
>>element values.
>> 
>>Yes, an array value ends at the boundary of its elements' values.
>> 
>>That fact is what allows the compiler to ignore mutation of 
>> the
>>buffer.
>> 
>>I don't know what you mean here.
>> 
>>It's perfectly clear that Array is a PureValue iff T is a 
>> PureValue.
>>PureValue is nothing more than transitive value semantics.
>> 
>>You're almost there.  “Transitive” implies that you are going to 
>> look at
>>the parts of a type to see if they are also PureValue's.  So 
>> which parts
>>of the Array struct does one look at, and why?  Just tell me the
>>procedure for determining whether a type is a PureValue.
>> 
>>We look at the observable parts.  
>> 
>>That begs the question.  The “parts” of an Array are the observable
>>features that are considered by equality.
>> 
>>We do not look at unobservable parts because we want flexibility to
>>use things like CoW, shared immutable references, etc in our
>>implementation.
>> 
>>IMO the important thing when it comes to functional purity is not what
>>you *can* observe, but what you *do* observe.
>> 
>>Can you share your definition of value semantics?  
>> 
>>Explaining it well and in sufficient detail for this discussion takes
>>some doing, but I think John Lakos and I share an understanding of value
>>semantics and he has a really detailed explanation in
>>https://www.youtube.com/watch?v=W3xI1HJUy7Q and
>>https://www.youtube.com/watch?v=0EvSxHxFknM.  He uses C++ in places,
>>but it's not particularly advanced, and the fundamental ideas apply just
>>as well to Swift.
>> 
>> Super interesting talk! 
>> 
>> But consider: isn't a single value type able to represent *multiple*
>> ethereal types?
> 
> “ethereal?”  Does he really use that term?  I don't know what it means.
> 
>> 
>> std::vector is a good example. What are the salient attributes of this
>> type? In the talk John says that
>> 
>> 1. the size is
>> 2. the values in the vector are
>> 3. the capacity, however *is not*
> 
> Yup, just like Array.  Thus the equality test for arrays ignores
> capacity.
> 
>> in which case std::vector would be an approximation of an ethereal
>> type which has a list of values, and the capacity is just an artifact
>> of the approximation. But you could also imagine an ethereal type
>> which *does* depend of the capacity of the object, and std::vector
>> unwittingly approximates that type 

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

[Luis Henrique B. Sousa via swift-evolution]

Yes. The suggested implementation does use min/max:

https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md#detailed-design

- Luis

On Sun, May 15, 2016 at 3:42 PM, Maximilian Hünenberger <
m.huenenber...@me.com> wrote:

> I brought these up because the current implementation produces an error in
> these cases. You have to insert additional min/max operations.
>
> Am 15.05.2016 um 16:38 schrieb Luis Henrique B. Sousa  >:
>
> Exactly, the idea is to return an empty array just like other languages
> do. (e.g. python)
>
> - Luis
>
> On Sun, May 15, 2016 at 10:13 AM, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On 15.05.2016 0:09, Maximilian Hünenberger via swift-evolution wrote:
>>
>>> One point which should be discussed is the following behaviour:
>>>
>>> let array = [0]
>>> // ranges are completely out of bounds and produce an error
>>> array[clamping: 1...2] // error
>>> array[clamping: -2...-1] // error
>>>
>>> Should a range which has no intersection with the indices of the
>>> collection
>>> produce an error or just clamp to 0..<0 respectively endIndex..>>
>>
>> I expect it will returns [] i.e. empty array, as no elements with
>> 1...2(-2..-1) indexes in the array. I understand `clamping` similar as
>> 'bounded','in these bounds'. And as soon as [0,1,2,3,4][clamping:2...10]
>> will silently move the right position to allowed index(4), and
>> [0,1,2,3,4][clamping:-2...0]  will move left position to 0, I expect that
>> in [0][clamping: 1...2] will try to move both limits to allowed, and as no
>> intersection - silently return empty array.
>>
>>
>>> Best regards
>>> Maximilian
>>>
>>> Am 13.05.2016 um 17:10 schrieb Luis Henrique B. Sousa via swift-evolution
>>> >:
>>>
>>> It seems that there is a consensus that this proposal might be a good
 addition to the standard library. All comments on this thread in the
 past
 few weeks were related to naming, not around the behaviour or validity
 of
 the proposed methods. So I will submit this proposal for review very
 soon
 assuming that nobody else has strong arguments against it. :-)

 Proposal:
 https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md

 If you have any corrections or suggestions to the proposal text itself,
 please comment on this gist:
 https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8
 (or pull request to my repo)

 Regards,

 - Luis

 On Tue, May 10, 2016 at 4:13 PM, Luis Henrique B. Sousa
 > wrote:

 Please let me know if you have more suggestions or corrections on
 this proposal.
 I'm tempted to submit it for review. :-)

 - Luis

 On Tue, May 10, 2016 at 8:53 AM, Luis Henrique B. Sousa
 > wrote:

 It sounds good, thanks for you suggestions @Vladimir, @Patrick
 and @Brent.

 I've just updated the proposal:

 https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md#detailed-design

 - Luis

 On Tue, May 10, 2016 at 6:50 AM, Vladimir.S via swift-evolution
 >
 wrote:

 Yes, I feel like 'within' is much better than 'bounded'.

 How about such changes in proposal:

 a[bounded: -1 ..< 5]  -->  a[within: -1 ..< 5]  (or
 a[inside:
 -1 ..< 5] )

 a[optional: 0 ..< 5]  -->  a[checking: 0 ..< 5]
 a[optional: 5]-->  a[checking: 5]

 ?

 On 10.05.2016 6:27, Patrick Smith via swift-evolution wrote:

 I like the idea of the of the bounded subscript, however
 the optional one I
 feel could be used for clumsy code.

 .first and .last have value, but once you start stepping
 several arbitrary
 indices in, then that code is likely fragile?


 I can think of ‘within’, ‘inside’ and ‘intersecting’ as
 alternative names
 for ‘bounded’ that attempt to explain what is going on:

 let a = [1, 2, 3]

 a[within: 0 ..< 5] // [1, 2, 3]
 a[inside: 0 ..< 5] // [1, 2, 3]
 a[intersecting: 0 ..< 5] // [1, 2, 3]


 On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa
  

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On May 16, 2016, at 8:17 AM, Tyler Fleming Cloutier via swift-evolution 
>  wrote:
> 
> 
>> On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Mon May 09 2016, Matthew Johnson  wrote:
>> 
 On May 8, 2016, at 1:51 AM, Dave Abrahams  wrote:
 
 
 on Sat May 07 2016, Andrew Trick  wrote:
>>> 
>   On May 7, 2016, at 2:04 PM, Dave Abrahams  wrote:
> 
>   2. Value types are not "pure" values if any part of the aggregate
>   contains a
>   reference whose type does not have value semantics. 
> 
>   Then Array is not a “pure” value (the buffer contained in an
>   Array is a mutable reference type that on its own, definitely does
>   *not* have value semantics). I don't think this is what you intend, and
>   it indicates that you need to keep working on your definition.
> 
> It sounds like you’re changing the definition of value semantics to make 
> it
> impossible to define PureValue. 
 
 Not on purpose.
 
> Does Array have value semantics then only if T also has value
> semantics?
 
 This is a great question; I had to rewrite my response four times.
 
 In my world, an Array always has value semantics if you respect the
 boundaries of element values as defined by ==.  That means that if T is
 a mutable reference type, you're not looking through references, because
 == is equivalent to ===.
 
 Therefore, for almost any interesting SomeConstraint that doesn't refine
 ValueSemantics, then
 
 Array
 
 only has value semantics if T has value semantics, since SomeConstraint
 presumably uses aspects of T other than reference identity.  
 
> The claim has been made that Array always has value semantics,
> implying that the array value’s boundary ends at the boundary of it’s
> element values.
 
 Yes, an array value ends at the boundary of its elements' values.
 
> That fact is what allows the compiler to ignore mutation of the
> buffer.
 
 I don't know what you mean here.
 
> It's perfectly clear that Array is a PureValue iff T is a PureValue.
> PureValue is nothing more than transitive value semantics.
 
 You're almost there.  “Transitive” implies that you are going to look at
 the parts of a type to see if they are also PureValue's.  So which parts
 of the Array struct does one look at, and why?  Just tell me the
 procedure for determining whether a type is a PureValue.
>>> 
>>> We look at the observable parts.  
>> 
>> That begs the question.  The “parts” of an Array are the observable
>> features that are considered by equality.
>> 
>>> We do not look at unobservable parts because we want flexibility to
>>> use things like CoW, shared immutable references, etc in our
>>> implementation.
>> 
>> IMO the important thing when it comes to functional purity is not what
>> you *can* observe, but what you *do* observe.
>> 
>>> Can you share your definition of value semantics?  
>> 
>> Explaining it well and in sufficient detail for this discussion takes
>> some doing, but I think John Lakos and I share an understanding of value
>> semantics and he has a really detailed explanation in
>> https://www.youtube.com/watch?v=W3xI1HJUy7Q and
>> https://www.youtube.com/watch?v=0EvSxHxFknM.  He uses C++ in places,
>> but it's not particularly advanced, and the fundamental ideas apply just
>> as well to Swift.
> 
> Super interesting talk! 
> 
> But consider: isn't a single value type able to represent *multiple* ethereal 
> types?
> 
> std::vector is a good example. What are the salient attributes of this type? 
> In the talk John says that
> 
> 1. the size is
> 2. the values in the vector are
> 3. the capacity, however *is not*
> 
> in which case std::vector would be an approximation of an ethereal type which 
> has a list of values, and the capacity is just an artifact of the 
> approximation. But you could also imagine an ethereal type which *does* 
> depend of the capacity of the object, and std::vector unwittingly 
> approximates that type too! In this case someone, unfamiliar with the 
> implementation might use it under the assumption that capacity *is* part of 
> the ethereal type and by extension the equality of std::vector. 

Yes, it is possible to look at every situation as a pure cross-product of ever 
single possibility, however that is of ten a source of waste as some are all 
clearly associated with a likelyhood of occurance. IMO does does not matter 
that *someone* might (and certainly will) when we can all agree that most would 
not. 

{bracket}I have watched some of the past discussion in the archive and noticed 
a number of situations when good proposals get derailed in the name of how 
difficult the syntax would become for 

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Tyler Fleming Cloutier via swift-evolution]

> On May 15, 2016, at 11:39 PM, Dave Abrahams  wrote:
> 
> 
> on Sun May 15 2016, Tyler Fleming Cloutier  wrote:
> 
>>On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>>on Mon May 09 2016, Matthew Johnson  wrote:
>> 
>>On May 8, 2016, at 1:51 AM, Dave Abrahams  
>> wrote:
>> 
>>on Sat May 07 2016, Andrew Trick  wrote:
>> 
>>  On May 7, 2016, at 2:04 PM, Dave Abrahams 
>>  wrote:
>> 
>>  2. Value types are not "pure" values if any part of the 
>> aggregate
>>  contains a
>>  reference whose type does not have value semantics. 
>> 
>>  Then Array is not a “pure” value (the buffer contained 
>> in an
>>  Array is a mutable reference type that on its own, 
>> definitely does
>>  *not* have value semantics). I don't think this is what you 
>> intend, and
>>  it indicates that you need to keep working on your 
>> definition.
>> 
>>It sounds like you’re changing the definition of value 
>> semantics to make it
>>impossible to define PureValue. 
>> 
>>Not on purpose.
>> 
>>Does Array have value semantics then only if T also has 
>> value
>>semantics?
>> 
>>This is a great question; I had to rewrite my response four times.
>> 
>>In my world, an Array always has value semantics if you 
>> respect the
>>boundaries of element values as defined by ==.  That means that 
>> if T is
>>a mutable reference type, you're not looking through references, 
>> because
>>== is equivalent to ===.
>> 
>>Therefore, for almost any interesting SomeConstraint that doesn't 
>> refine
>>ValueSemantics, then
>> 
>>Array
>> 
>>only has value semantics if T has value semantics, since 
>> SomeConstraint
>>presumably uses aspects of T other than reference identity.  
>> 
>>The claim has been made that Array always has value semantics,
>>implying that the array value’s boundary ends at the boundary 
>> of it’s
>>element values.
>> 
>>Yes, an array value ends at the boundary of its elements' values.
>> 
>>That fact is what allows the compiler to ignore mutation of 
>> the
>>buffer.
>> 
>>I don't know what you mean here.
>> 
>>It's perfectly clear that Array is a PureValue iff T is a 
>> PureValue.
>>PureValue is nothing more than transitive value semantics.
>> 
>>You're almost there.  “Transitive” implies that you are going to 
>> look at
>>the parts of a type to see if they are also PureValue's.  So 
>> which parts
>>of the Array struct does one look at, and why?  Just tell me the
>>procedure for determining whether a type is a PureValue.
>> 
>>We look at the observable parts.  
>> 
>>That begs the question.  The “parts” of an Array are the observable
>>features that are considered by equality.
>> 
>>We do not look at unobservable parts because we want flexibility to
>>use things like CoW, shared immutable references, etc in our
>>implementation.
>> 
>>IMO the important thing when it comes to functional purity is not what
>>you *can* observe, but what you *do* observe.
>> 
>>Can you share your definition of value semantics?  
>> 
>>Explaining it well and in sufficient detail for this discussion takes
>>some doing, but I think John Lakos and I share an understanding of value
>>semantics and he has a really detailed explanation in
>>https://www.youtube.com/watch?v=W3xI1HJUy7Q and
>>https://www.youtube.com/watch?v=0EvSxHxFknM.  He uses C++ in places,
>>but it's not particularly advanced, and the fundamental ideas apply just
>>as well to Swift.
>> 
>> Super interesting talk! 
>> 
>> But consider: isn't a single value type able to represent *multiple*
>> ethereal types?
> 
> “ethereal?”  Does he really use that term?  I don't know what it means.

He does pretty frequently. He also refers to them as Mathematical Types. He 
means the logical type that the C++ implementation is supposed to approximate.

An example he gives is int and how it only approximates the logical Integer 
type, because it is represented in many ways, e.g. short, int, long, long long. 
None of them are exactly the same the logical type.

> 
>> 
>> std::vector is a good example. What are the salient attributes of this
>> type? In the talk John says that
>> 
>> 1. the size is
>> 2. the values in the vector are
>> 3. the capacity, however *is not*
> 
> Yup, just like Array.  Thus the equality test for arrays ignores
> capacity.
> 
>> in 

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[L. Mihalkovic via swift-evolution]

On May 16, 2016, at 12:45 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> Being able to let the developer decide how to place relevant type 
>> information with the freedom of being able to keep some/all/none type 
>> information local and some/none/all extra information moved to the end of 
>> the declaration.
> 
> To be clear, I do think it makes sense to move *all* `where` clauses to the 
> end of the parameter list, not allow them both within the angle brackets and 
> at the end of the definition. And I'm not convinced it makes sense to support 
> moving all conformance information to the `where` clause, either. A generic 
> parameter list like `` is vacuous; when you're dealing with something 
> like this:
> 
>public func transcode
> UnicodeCodec>
>(_ input: Input, from inputEncoding: InputEncoding.Type, to 
> outputEncoding: OutputEncoding.Type, stoppingOnError stopOnError: Bool, 
> sendingOutputTo processCodeUnit: @noescape (OutputEncoding.CodeUnit) -> Void) 
> -> Bool
>where InputEncoding.CodeUnit == Input.Element
> 
> The detail in the `where` clause really is of secondary importance, 
> especially compared to how much syntax it takes to specify, while this:
> 
>public func transcode
>(_ input: Input, from 
> inputEncoding: InputEncoding.Type, to outputEncoding: OutputEncoding.Type, 
> stoppingOnError stopOnError: Bool, sendingOutputTo processCodeUnit: @noescape 
> (OutputEncoding.CodeUnit) -> Void) -> Bool
>where Input: IteratorProtocol, InputEncoding: UnicodeCodec, 
> OutputEncoding: UnicodeCodec, InputEncoding.CodeUnit == Input.Element
> 
> Leaves far too much unspecified until the end.

Purely a matter of opinion... I'm fine with it.

> 
> I'm actually tempted to suggest that a conformance should be *mandatory* and 
> you should have to specify `Any` if you don't have anything more specific to 
> say about the generic parameter:
> 
>func map(@noescape transform: (Element) throws -> T) rethrows -> 
> [T]
> 
> That would penalize the "leave everything until the end" style without 
> actually introducing any arbitrary rules forbidding it.
> 
> -- 
> 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