Re: [swift-evolution] Subclass Existentials

typealias AnyObject = … is nice to have, but how about if we fully drop the class constraint-keyword and generalize AnyObject instead? In the future we might want to add AnyValue with value (semantics) constraint, would that mean that we’d need another keyword there like value? The former is si

Re: [swift-evolution] Strings in Swift 4

> On Feb 1, 2017, at 2:30 PM, Nate Cook via swift-evolution > wrote: > > With a lot of these new features, it helps me greatly to see them in action. > I've built a poor man's version of these incomplete ranges in a Swift Sandbox > here: > http://swiftlang.ng.bluemix.net/#/repl/58925f5d4

Re: [swift-evolution] Proposal seed: gathering data to fix the NSUInteger inconsistency

I have a framework I wrote that maps Objective C objects to sqlite records - deriving sqlite schema definitions from property definitions. You simply derive model classes from my base class Model and the base class will introspect the properties and handle all the sql for you. A little like C

Re: [swift-evolution] Subclass Existentials

Sent from my iPhone > On Feb 1, 2017, at 8:46 PM, Slava Pestov wrote: > > >>> On Feb 1, 2017, at 4:09 PM, Douglas Gregor via swift-evolution >>> wrote: >>> >>> >>> On Feb 1, 2017, at 3:13 PM, David Hart wrote: >>> >>> Second question inline: >>> >>> >>> >>> Sent from my iPhone >>> On

Re: [swift-evolution] Subclass Existentials

> On Feb 1, 2017, at 4:09 PM, Douglas Gregor via swift-evolution > wrote: > >> >> On Feb 1, 2017, at 3:13 PM, David Hart > > wrote: >> >> Second question inline: >> >> >> >> Sent from my iPhone >> On 1 Feb 2017, at 23:09, David Hart > > w

[swift-evolution] Proposal seed: gathering data to fix the NSUInteger inconsistency

Hey, swift-evolution. I want to draw attention to one of the oddest parts of the Objective-C importer today: NSUInteger. TLDR: NSUInteger is treated differently based on whether it comes from a system framework or a user-provided header file. I think this is silly and that we should treat it co

Re: [swift-evolution] Subclass Existentials

> On Feb 1, 2017, at 4:06 PM, Douglas Gregor wrote: > > Personally, I like having the requirement that the class come first. It fits > with the requirement we already have for classes that have a superclass. I guess I’ll throw my hat into the ring and +1 this too. What if there are multiple c

Re: [swift-evolution] Subclass Existentials

> On Feb 1, 2017, at 3:13 PM, David Hart wrote: > > Second question inline: > > > > Sent from my iPhone > On 1 Feb 2017, at 23:09, David Hart > wrote: > >> I did consider it, but didn’t want to put too much on your plate for Swift >> 4. But if you’re mentioning it

Re: [swift-evolution] Subclass Existentials

> On Feb 1, 2017, at 2:09 PM, David Hart wrote: > > I did consider it, but didn’t want to put too much on your plate for Swift 4. Quite appreciated! Cleaning up AnyObject happens to be on my list of ABI-impacting changes I’m itching to make ;) > But if you’re mentioning it, I’ll go ahead and

Re: [swift-evolution] Subclass Existentials

I did consider it, but didn’t want to put too much on your plate for Swift 4. But if you’re mentioning it, I’ll go ahead and add it to the second version of the proposal. By the way, what you is your point of view about the discussions we’ve had concerning the positioning of the class constrain

Re: [swift-evolution] Subclass Existentials

Sent from my iPad > On Feb 1, 2017, at 5:11 PM, David Sweeris via swift-evolution > wrote: > > >> On Feb 1, 2017, at 3:01 PM, David Hart via swift-evolution >> wrote: >> >> >> On 1 Feb 2017, at 22:54, Douglas Gregor wrote: >> >>> On Jan 29, 2017, at 8:44 PM, Slava Pestov via swif

Re: [swift-evolution] Subclass Existentials

> On Feb 1, 2017, at 15:17, David Hart wrote: > > > On 2 Feb 2017, at 00:06, Jordan Rose > wrote: > >> I agree with Chris on both counts. Either we need to continue to import >> ‘NSFoo *’ as ‘NSFoo’ in the Swift 4 compiler’s “Swift 3 >> compatibility mode”, or

Re: [swift-evolution] Subclass Existentials

> On 2 Feb 2017, at 00:06, Jordan Rose wrote: > > I agree with Chris on both counts. Either we need to continue to import > ‘NSFoo *’ as ‘NSFoo’ in the Swift 4 compiler’s “Swift 3 compatibility > mode”, or we need to come up with all the cases where a normally-unsound > conversion needs to b

Re: [swift-evolution] Subclass Existentials

I agree with Chris on both counts. Either we need to continue to import ‘NSFoo *’ as ‘NSFoo’ in the Swift 4 compiler’s “Swift 3 compatibility mode”, or we need to come up with all the cases where a normally-unsound conversion needs to be permitted (possibly with a warning) in order to avoid bre

Re: [swift-evolution] Subclass Existentials

Second question inline: Sent from my iPhone > On 1 Feb 2017, at 23:09, David Hart wrote: > > I did consider it, but didn’t want to put too much on your plate for Swift 4. > But if you’re mentioning it, I’ll go ahead and add it to the second version > of the proposal. > > By the way, what yo

Re: [swift-evolution] Subclass Existentials

> On Feb 1, 2017, at 3:01 PM, David Hart via swift-evolution > wrote: > > > On 1 Feb 2017, at 22:54, Douglas Gregor > wrote: > >> >>> On Jan 29, 2017, at 8:44 PM, Slava Pestov via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> This is a nic

Re: [swift-evolution] Subclass Existentials

> On 1 Feb 2017, at 22:54, Douglas Gregor wrote: > > >> On Jan 29, 2017, at 8:44 PM, Slava Pestov via swift-evolution >> wrote: >> >> This is a nice generalization of the existing protocol composition syntax. >> Implementation might get a little tricky — this touches a lot of things, >> su

Re: [swift-evolution] Strings in Swift 4

With a lot of these new features, it helps me greatly to see them in action. I've built a poor man's version of these incomplete ranges in a Swift Sandbox here: http://swiftlang.ng.bluemix.net/#/repl/58925f5d42b65e6dce9a5bea This implementation suffers greatly from a lack of generic subs

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 8:39 AM, David Hart wrote: > > Hello, > > As promised, I wrote the first draft of a proposal to add class requirements > to the existential syntax. Please let me know what you think. > > https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 8:44 PM, Slava Pestov via swift-evolution > wrote: > > This is a nice generalization of the existing protocol composition syntax. > Implementation might get a little tricky — this touches a lot of things, such > as inheritance clauses, constraints in generic signatures,

Re: [swift-evolution] for-else syntax

+1 This is generally why I've suggested about a week or two ago "NonEmptyArray" - an array that ensures it's not empty. Which is IMHO a sensible thing to use sometimes instead... > On Feb 1, 2017, at 8:38 PM, Sean Heber via swift-evolution > wrote: > > I usually use guard (or sometimes if) a

Re: [swift-evolution] Strings in Swift 4

> Am 01.02.2017 um 19:37 schrieb Ben Cohen via swift-evolution > : > > there is a legitimate quibble here that this will translate into > arr[0.. invalid. But 0..< is ugly so we should ignore this quibble for the sake of > aesthetics If we just say that ... implies arr[0...arr.lastIndex] wher

Re: [swift-evolution] protocol-oriented integers (take 2)

The problem with moving divided(by:) to DoubleWidth is that over there. When `dividing(_:)` is on the FixedWidthInteger conforming type, Self is known and it is possible to implement this operation efficiently. If it moves to the DoubleWidth, because T is just “something that conforms to Fixed

Re: [swift-evolution] for-else syntax

I usually use guard (or sometimes if) and an early return: func run() { guard !names.isEmpty else { /* stuff */ return } /* stuff with names */ } l8r Sean > On Feb 1, 2017, at 12:18 PM, Nicolas Fezans via swift-evolution > wrote: > > I tend to write this kind of treatment t

Re: [swift-evolution] for-else syntax

collection ifEmpty:[ "" ] ifNotEmptyDo: [:each | "" ] > On Feb 1, 2017, at 10:29, Chris Davis via swift-evolution > wrote: > > ah! I forgot about the break semantics, that’s definitely one for the con > list. > > I like Nicolas’ solution, clear to read. > >> On 1 Feb 2017, at 18:

Re: [swift-evolution] Strings in Swift 4

I think Dave has already made these points separately but it probably helps to recap more explicitly the behavior we expect from “x…" Names are just for discussion purposes, exact naming can be left as a separate discussion from functionality: - Informally, one-sided ranges are a thing. Formal

Re: [swift-evolution] protocol-oriented integers (take 2)

on Tue Jan 31 2017, Xiaodi Wu wrote: > Why not move the `dividing` version to DoubleWidth, where it can be > a proper `divided(by:)`? Why didn't I think of that? :-) -- -Dave ___ swift-evolution mailing list swift-evolution@swift.org https://lists.s

Re: [swift-evolution] for-else syntax

ah! I forgot about the break semantics, that’s definitely one for the con list. I like Nicolas’ solution, clear to read. > On 1 Feb 2017, at 18:18, Nicolas Fezans wrote: > > I tend to write this kind of treatment the other way around... > > if names.isEmpty { > // do whatever > } // on o

Re: [swift-evolution] for-else syntax

I tend to write this kind of treatment the other way around... if names.isEmpty { // do whatever } // on other cases I might have a few else-if to treat other cases that need special treament else { for name in names { // do your thing } } Nicolas Fezans On Wed, Feb 1, 2017 at 6:31 PM, Saagar

Re: [swift-evolution] for-else syntax

I ran into this not too long ago. Something to handle this case would definitely be nice, but I agree we shouldn’t take python’s syntax with different semantics. > On Feb 1, 2017, at 9:30 AM, Dimitri Racordon via swift-evolution > wrote: > > I agree. A for-else loop with different semantics t

Re: [swift-evolution] for-else syntax

If you’re fine with a couple extra characters, you can use .isEmpty: for name in names { // do your thing } if names.isEmpty { // do whatever } It’s a bit more typing, but I feel it makes your intentions more clear. Saagar Jha > On Feb 1, 2017, at 8:48 AM, Chris Davis via swift-

Re: [swift-evolution] for-else syntax

I agree. A for-else loop with different semantics than python would be error-prone for many people. On 1 Feb 2017, at 18:17, Jacob Bandes-Storch via swift-evolution mailto:swift-evolution@swift.org>> wrote: One possible con: this is subtly but extremely different from Python, where a for loop

Re: [swift-evolution] [Discussion] mailing list alternative

I for one absolutely dislike using mail clients. The mail is a relic of the past that should burn in hell! Jokes aside, I actually find it very difficult to keep track of the threads. I often end up having my client sorting the messages of one thread in a different group, probably because the a

Re: [swift-evolution] for-else syntax

One possible con: this is subtly but extremely different from Python, where a for loop's else clause is executed only if there was no `break` from the loop. On Wed, Feb 1, 2017 at 8:48 AM Chris Davis via swift-evolution < swift-evolution@swift.org> wrote: > Hi, > > Often when I’m programming I stu

Re: [swift-evolution] for-else syntax

You can write a helper method that adds a placeholder if the array is empty: for name in names.placeholder("no names") { print(name) } Implementation: extension Collection { func placeholder(_ elem: Iterator.Element) -> PlaceholderView { return Placeholder

Re: [swift-evolution] Strings in Swift 4

I had read the discussion live as it happened. And just now I went back to see Jaden’s posts again: there are only a handful, and all are quite brief. To the extent that they “sketched a direction”, I would say no. We should instead base the proposal on ideas laid out by Dave Abrahams, Brent Royal-

Re: [swift-evolution] [Discussion] mailing list alternative

> On 25 Jan 2017, at 23:34, Erica Sadun via swift-evolution > wrote: > > >> On Jan 25, 2017, at 1:05 PM, Ted Kremenek via swift-evolution >> wrote: >> >> I have no problem with the project moving to forums instead of the Mailman >> mailing lists we have now — if it is the right set of trad

[swift-evolution] for-else syntax

Hi, Often when I’m programming I stumble upon this scenario: I have a list of items that may or may not be empty - if it’s full, I do one thing, if it’s empty I do something else, my code looks like this: class Example_1 { let names = ["Chris", "John", "Jordan"] /// Loop over names

Re: [swift-evolution] Strings in Swift 4

Drafting a proposal sounds like a good idea, to establish all the relevant information in one place. I don’t recall off the top of my head what directions Jaden sketched out, but as long as the proposal hits the high points of the uses and benefits, and summarizes the discussion and alternatives, i

Re: [swift-evolution] Strings in Swift 4

> On Feb 1, 2017, at 9:52 AM, Nevin Brackett-Rozinsky > wrote: > > Drafting a proposal sounds like a good idea, to establish all the relevant > information in one place. I don’t recall off the top of my head what > directions Jaden sketched out, but as long as the proposal hits the high > po

Re: [swift-evolution] Strings in Swift 4

> On Feb 1, 2017, at 9:15 AM, Nevin Brackett-Rozinsky > wrote: > > I am also +1. > > > On Wed, Feb 1, 2017 at 9:29 AM, Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > I’m still curious how postfix `…` would impact our options for variadic > generics and

Re: [swift-evolution] Strings in Swift 4

I am also +1. On Wed, Feb 1, 2017 at 9:29 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > I’m still curious how postfix `…` would impact our options for variadic > generics and tuple unpacking in the future. Somebody who happens to have originally created Swift

Re: [swift-evolution] Strings in Swift 4

Brent-- In general, I agree with the direction of your thinking. Time constraints prevent me from responding as thoroughly as I'd like, but briefly, where we don't agree at the moment boil down to a few points: * Agree that "to" vs "through" is not ideal. However, having spent a lot of time on th

Re: [swift-evolution] Strings in Swift 4

> On Feb 1, 2017, at 6:58 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> Therefore I'd conclude that `arr[upTo: i]` is the most consistent spelling. >> It also yields the sensible result that `arr[from: i][

Re: [swift-evolution] Strings in Swift 4

I entirely agree with you on the desired behavior of `zip(...)`. However, if you insist on 0... being notionally an infinite range, then you would have to insist on `for i in 0...` also trapping. Which is not a big deal, IMO, but will surely make the anti-trapping crowd upset. The bigger issue is

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu via swift-evolution > wrote: > > Therefore I'd conclude that `arr[upTo: i]` is the most consistent spelling. > It also yields the sensible result that `arr[from: i][upTo: j] == arr[upTo: > j][from: i] == arr[i.. Range } And then reduce the many

Re: [swift-evolution] [Discussion] mailing list alternative

> On 1 Feb 2017, at 06:59, Thorsten Seitz via swift-evolution > wrote: > > While I'm not really happy with the mailing list, this is mostly due to > restrictions of iOS Mail which makes keeping track of relevant threads and > filtering out threads I'm not interested in difficult. > > The ma

Re: [swift-evolution] @NSCopying currently does not affect initializers

Oh sorry, perhaps I confused the standard procedure. Best, Torin Kwok On Wed, Feb 1, 2017 at 3:34 PM +0800, "Torin Kwok via swift-evolution" wrote: I have given out a proposal about it: Compensate for the inconsistency of @NSCopying's behavior. Please give it some reviews. Thanks.