Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

> [...] > > I don’t agree that the Collection should be Int-indexed. Source-order is not > a very strong guarantee IMO, and it wouldn’t be good if people started > writing things like "MyEnum.allValues[3]” to reference a specific case. So how do you propose to use allValues with a table view?

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

> Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

>>> [...] >>> 2️⃣ If the enum is NOT decorated with @frozen, then I, as an app >>> author, have to account for the possibility that the module may update from >>> underneath my app, and I have to handle an unknown case. This is simple: >>> the compiler should require me to add a “default:”

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[...] >> in what other circumstances do we insist that the compiler inform the end >> user about future additions to the API at compile time? > > This isn’t a request for the compiler to inform the user about future > additions to an API. It is a request to validate the compiler’s knowledge

Re: [swift-evolution] Enums and Source Compatibility

> On Oct 2, 2017, at 2:10 PM, Jordan Rose via swift-evolution > wrote: > > I don't think I have anything to say on this topic that I haven't already > said: > > - Switching exhaustively over non-exhaustive enums is uncommon. [Citation Needed] As I pointed out in

Re: [swift-evolution] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

>> [...] > > Hi, Nacho. This is discussed in the proposal as "'future' cases" under > "Alternatives considered". The main blocker was that such a case becomes > untestable (see also "Testing invalid cases"). That didn't seem like an > acceptable state of affairs to me or to the people I had

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution > wrote: > > The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through > January 3, 2018. > > The proposal is available here: > >

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

I agree this would be useful. At the moment I have to hack around it with things like `var isFoo: Bool { if case .foo = self …`* with cases I commonly need, but this is definitely a feature that has come up before and I support. It is potentially related to getting the values through an

Re: [swift-evolution] Refining SE-0185: Should providing a custom == suppress the default hashValue?

I’m skeptical that your use case is common enough to justify leaving open the glaring bug magnet that started this thread. Could you give an example of a common occurrence where it would be a significant improvement to explicitly write a *less precise* hash function that’s only “good enough”

Re: [swift-evolution] [Idea] [Pitch] Add `match` statement as `switch`-like syntax alternative to `if case` pattern matching

There have been earlier suggestions for an alternative to `fallthrough` that would continue matching cases; I think that is much more likely to get support than a whole new construct with only a subtle difference from an existing one—would that be an acceptable alternative to you? > On Nov 17,

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

As far as the Sequence overloads: I really, really think we should go a step beyond renaming and separate the functions into the underlying operations. FlatMap has three separate and orthogonal effects, so it should be split into three functions—flatten, map, and dropNil. Map already exists,

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

So, what I'm getting from this explanation is that `Equatable` is meaningless on its own; each class needs to document exactly what "substitutability" means as implemented, and any code that uses `==` needs to check the documentation for that specific class and make sure the intended use

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 17, 2017, at 11:47 AM, Michael Ilseman <milse...@apple.com> wrote: > > > >> On Oct 17, 2017, at 10:15 AM, Kevin Nattinger via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>>

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

>>> set.elementsEqual(set) >> >> I see why that would work (thanks to Set being a collection vs a sequence), >> but it still feels like a hack. I definitely wouldn’t want to be >> maintaining code with that in it. Especially when compared to something like: >> >> set.contains(where:

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 17, 2017, at 10:36 AM, Adam Kemp wrote: > > >> On Oct 17, 2017, at 10:00 AM, Kevin Nattinger > > wrote: >> >> Once we allow covariant functions to satisfy protocol requirements and have >> generalized

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 16, 2017, at 1:29 PM, Adam Kemp via swift-evolution > wrote: > > > >> On Oct 16, 2017, at 12:35 PM, Thorsten Seitz via swift-evolution >> > wrote: >> >> IMHO `elementsEqual` provides a nice

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Because, in my analysis, the problem is that the method is incorrectly named. > The problem affects all types that conform to Sequence and not just Set and > Dictionary; elementsEqual is a distinct function from ==, and it must either > continue to be distinct or cease to exist, but its name

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 16, 2017, at 1:08 PM, Xiaodi Wu via swift-evolution > wrote: > > > On Mon, Oct 16, 2017 at 13:15 David Sweeris > wrote: > > On Oct 16, 2017, at 09:21, Michael Ilseman

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 16, 2017, at 11:23 AM, David Sweeris via swift-evolution > wrote: > > > On Oct 16, 2017, at 10:42, BJ Homer via swift-evolution > > wrote: > >>> On Oct 16, 2017, at 8:20 AM, Thorsten Seitz via

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 16, 2017, at 10:43 AM, BJ Homer via swift-evolution > wrote: > >> On Oct 16, 2017, at 8:20 AM, Thorsten Seitz via swift-evolution >> > wrote: >> >>> Am 16.10.2017 um 07:19 schrieb Xiaodi Wu

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

>> >> How is the iteration order of an unordered set or dictionary “publicly >> observable”? If either is implemented such that it can asynchronously >> optimize its storage (maybe by rebalancing a tree or merging two >> non-contiguous array segments or something), its iteration order could

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

>> […] >> Set conforming to Collection is even worse than just conforming to Sequence >> as a quote from the documentation shows: "In addition to the operations that >> collections inherit from the Sequence protocol, you gain access to methods >> that depend on accessing an element at a

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> […] > Swift's Sequence protocol does not require the order of iteration to "convey > any meaning"; it doesn't even require it to be deterministic. > And that’s EXACTLY why none of the functions on Sequence should rely on the order conveying meaning. `ElementsEqual` (for example) DOES rely

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> […] > Sets, as a mathematical concept, have no intrinsic order. However, instances > of `Set`, which can be iterated over, *do* have at least one order which can > be said to be intrinsic in the following sense: as long as iteration is > possible, no API design can prevent that order from

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 14, 2017, at 7:54 PM, Xiaodi Wu wrote: > > On Sat, Oct 14, 2017 at 6:17 PM, Kevin Nattinger > wrote: >>> […] >>> * A Swift `Sequence` is, to put it simplistically, a thing that can be >>> iterated over in a

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

>> […] >> * A Swift `Sequence` is, to put it simplistically, a thing that can be >> iterated over in a `for...in` loop. If it would make you happy, for the rest >> of the discussion, let's suppose we called the protocol `ForLoopable` >> instead of `Sequence`. > > ForLoopable is so ugly. Since

[swift-evolution] Fwd: [Draft] Rename Sequence.elementsEqual

> Begin forwarded message: > > From: Kevin Nattinger > Subject: Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual > Date: October 14, 2017 at 12:52:34 AM PDT > To: Xiaodi Wu > >> […] >> Regardless of the specific type of ordering,

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 13, 2017, at 8:28 PM, Xiaodi Wu wrote: > > > > On Fri, Oct 13, 2017 at 12:03 PM, Kevin Nattinger > wrote: >> On Oct 13, 2017, at 6:52 AM, Xiaodi Wu > > wrote:

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> > Is seems like you’re arguing we should attack the “Ordered versus unordered” > dichotomy prior to any name change. Is that correct? > Yes, that's exactly my primary argument. (The secondary argument being that in either case the name should not be changed, at least not to the proposed

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 13, 2017, at 10:01 AM, Michael Ilseman <milse...@apple.com> wrote: > > > >> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> –∞ >&g

[swift-evolution] Fwd: [Draft] Rename Sequence.elementsEqual

ed. >> Sure i may pester a bit when the code doesn't compile, but it sure is better >> than discovering the weird behavior of a badly defined protocol hierarchy in >> customer support. >> >> >> On Fri, Oct 13, 2017 at 6:57 AM, Kevin Nattinger via swift-ev

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> 1. We could go ahead and make this separation. Although it's a potentially > large breaking change, I would argue that because the methods are ill-defined > anyway, the breakage is justified and a net benefit. > > 2. We could try and think of a way to make the distinction between ordered >

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

–∞ 1. I strongly object to the proposed name. It doesn't make it more clear to me what the method does, and is misleading at best. Among other issues, "lexicographical" is defined as alphabet order, and (1) this method applies to objects that are not Strings, and (2) this method's behavior

Re: [swift-evolution] [Proposal] Random Unification

> On Oct 12, 2017, at 6:13 AM, Jeremy Pereira > wrote: > > > >> On 11 Oct 2017, at 18:01, Kevin Nattinger wrote: >> >> IMO, if we have the extensions on Int(eger)/Float(ingPoint)/Array >> (RandomAccessSequence?), they should just be for

Re: [swift-evolution] [Proposal] Random Unification

IMO, if we have the extensions on Int(eger)/Float(ingPoint)/Array (RandomAccessSequence?), they should just be for convenience and with a sane default RNG*, and users that need more should just use methods on the RNGs directly. *: I don't think the default necessarily needs to be a CSRNG; if

Re: [swift-evolution] [Proposal] Random Unification

> On Sep 8, 2017, at 2:46 PM, Jacob Williams via swift-evolution > wrote: > > What if we did it with something like this: > > protocol RandomGenerator { > associated type T: Numeric // Since numeric types are the only kinds > where we could get a random

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

I've been waiting for this for years. Literally since Swift was announced. IMO it's one of several major gaps in the language. Some thoughts: - It should be a simple array. - By far the most simple solution, and the one I (and, I'd guess, others) would expect. - Every time I've

Re: [swift-evolution] [Proposal] Random Unification

IMO, we should have a `Random` or `RandomGenerator` interface and the stdlib can provide a `SystemRandom` that wraps arc4*/random(), and maybe a cryptographically secure one too (MT19937?). protocol RandomGenerator { func uniform() -> Int func uniform() -> Double func

Re: [swift-evolution] Introducing synthesized locks

I'd prefer to see block-scoped synchronization rather than whole-method-only; it gives much more flexibility. Note that you can use the objc synchronization feature with reference types: // Or (_ obj:...) if you prefer the label-less objc style) func synchronized(on obj: AnyObject, do block: ()

Re: [swift-evolution] Proposal: Allow #if to guard switch case clauses

I support this proposal 100%. In fact, I just ran into this use case. I’d support extending it to allow partial-case coverage (as long as it doesn’t cross a case: boundary, obviously), e.g. switch result { case .success(let object): doSomething(with: object) case .error(let error): #if

Re: [swift-evolution] [Pitch] Enum with generic cases

> On Apr 24, 2017, at 3:16 PM, Jaden Geller wrote: > > >> On Apr 24, 2017, at 2:38 PM, Kevin Nattinger > > wrote: >> >>> >>> How can I improve your understanding? >>> >> >> >> Given the enum I was using earlier: >>

Re: [swift-evolution] [Pitch] Enum with generic cases

> > How can I improve your understanding? > Given the enum I was using earlier: enum Thing { case thingOne(T) case thingTwo(T) } - Write a function that takes a thingOne or thingTwo but nothing else. - Declare a variable that can hold a thingOne or thingTwo but nothing else. Or

Re: [swift-evolution] [Pitch] Enum with generic cases

> On Apr 24, 2017, at 1:36 PM, Jaden Geller <jaden.gel...@gmail.com> wrote: > >> >> On Apr 24, 2017, at 1:15 PM, Kevin Nattinger via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> This makes

Re: [swift-evolution] [Pitch] Enum with generic cases

> On Apr 24, 2017, at 1:34 PM, Joshua Alvarado > wrote: > > Well in your case thing one and thing two will be the same type as you are > using the same T generic type on both. It’s two different and unrelated generics unless you’re intending to change the way

Re: [swift-evolution] [Pitch] Enum with generic cases

This makes it more convenient to create them, sure, but how would you pass them around or extract the value in a type-safe manner? e.g. now I can write: enum Thing { case thingOne(T) case thingTwo(U) } // How do I require thingOne or thingTwo? func handle(thing: Thing

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

I agree, but unfortunately it’s probably too late now. > On Apr 19, 2017, at 3:11 PM, Martin Waitz via swift-evolution > wrote: > > Hi, > > I think, it would be more natural to include the last newline. > Multi-line String literals are for multiple lines. > And each

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

Not to mention that many IDEs (at least have options to) trim trailing whitespace automatically, so it has a fair to high likelihood of breaking unexpectedly and invisibly. > On Apr 19, 2017, at 3:09 PM, Joe Groff via swift-evolution > wrote: > > >> On Apr 19,

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

array.remove(where: { $0 > 3 }) array.remove { $0 > 3 } > On Apr 10, 2017, at 12:25 PM, David Hart via swift-evolution > wrote: > > > > On 10 Apr 2017, at 17:17, Maximilian Hünenberger via swift-evolution >

Re: [swift-evolution] switch must be exhaustive, consider adding a default clause

> On Apr 10, 2017, at 9:18 AM, Josh Parmenter via swift-evolution > wrote: > > case .none isn’t handled. It shouldn’t need to be handled in the second switch because it’s impossible. Not just developer thinks “impossible” but easily provable by static analysis the

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution > wrote: > > Looking at 3) which is underspecified in the proposal perhaps, I’d consider > it a “feature" but I can see it would be too magical for some. To specify it > more you could say: if there

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

I am 110% AGAINST this change. Having complex expressions as a stored property initializer is bad practice anyway, and having the type prefixed in that case provides at best marginal improvement in clarity and doesn’t fix the underlying problem. Type inference on simple expressions allows

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> On Apr 6, 2017, at 6:10 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0169 "Improve Interaction Between private Declarations and > Extensions" begins now and runs through April 11, 2017. The proposal is >

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 6, 2017, at 2:35 PM, Joe Groff via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0168 "Multi-Line String Literals" begins now and runs > through April 12, 2017. The proposal is available here: > >

Re: [swift-evolution] Type-based ‘private’ access within a file

>> On Apr 5, 2017, at 6:54 PM, Nevin Brackett-Rozinsky via swift-evolution >> > wrote: >> >> On Wed, Apr 5, 2017 at 12:02 AM, Chris Lattner via swift-evolution >> > wrote:

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

I definitely think we should stick with `all` and an appropriate argument label. It’s a term of art and the label makes it perfectly clear what to expect. That said, `all(match)` and `all(equal)` sound to me like they expect an object to compare each against (func all(equal needle: Element)) I

Re: [swift-evolution] [swit-evolution] [Review] SE-0156: Class and Subtype existentials

> What is your evaluation of the proposal? +0.9 The core of the proposal is unquestionably necessary to correct a serious deficiency in the expressivity of the type system, but I take issue with the arbitrary limitation of requiring the concrete type to be first and would give a full +1 to the

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> … > Additionally, the design allows ‘final’ to take any one of those visibility > levels as a parameter, to indicate that the type should be treated as ‘final’ > at and above the specified scope. Thus ‘final(public)’ prevents subclassing > outside the module, while ‘final(internal)’ prevents

Re: [swift-evolution] [Pitch/Reality Check] Allow instance members as parameter default values

> On Feb 22, 2017, at 8:25 PM, Derrick Ho via swift-evolution > wrote: > > Did you know you can use a static variable as a default parameter? > > class poncho { > static var color= "yellow" > > func foo(color: String = poncho.color){} > } > > I think instance

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

I don’t think we need/want to add `@objcstring` or anything like that, but I do think we should let String enums be @objc (currently it’s int types only) and imported as const refs. // Already works @objc enum IntEnum: Int { case foo = 1 case bar = 2 } // "not an integer type" //

Re: [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

> On Feb 18, 2017, at 7:33 PM, Chris Lattner via swift-evolution > wrote: > > >> On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution >> > wrote: >> >> I’d like to revive an additive proposal

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 17, 2017, at 11:50 AM, Adrian Zubarev via swift-evolution > wrote: > > Sorry, I couldn’t follow every thread. I simply couldn’t get that fact from > the given context of the first post by Anton. :) Just forget everything I > mentioned about typealias,

Re: [swift-evolution] [Pitch] Typed throws

protocol MyError: Error {} enum MyFooError: MyError { … } enum MyBarError: MyError { … } func baz() throws(MyError) > On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution > wrote: > > I suggest we need to find a way to shorten the list of the possible

Re: [swift-evolution] Pitch: Replacement for FileHandle

> On Feb 15, 2017, at 3:45 PM, Tony Parker via swift-evolution > wrote: > >> >> On Feb 15, 2017, at 2:25 PM, Charles Srstka > > wrote: >> >>> On Feb 15, 2017, at 3:11 PM, Itai Ferber

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

Re: [swift-evolution] Subclass Existentials

+1 on including concrete types, this is currently a gaping hole in the language. -100 on requiring the concrete type to be first. If I want to specify the types alphabetically, grouped by module, or any other way I choose, why should I not be allowed to do so? The compiler can warn on

Re: [swift-evolution] Throws? and throws!

> On Jan 12, 2017, at 3:50 PM, Xiaodi Wu via swift-evolution > wrote: > > Some additional thoughts: if I recall correctly from my (limited) Java days, > throwing in Java worked essentially like your proposed `throws!`. That the > Swift model expressly deviates from

Re: [swift-evolution] Add code to super methods.

I agree. An NS_REQUIRES_SUPER equivalent was on my list of things to propose during stage 2, and I don't see a reason to enforce order. > On Nov 25, 2016, at 04:42, Tino Heth via swift-evolution > wrote: > > >> What are your thoughts on this? >> >> Just to throw

Re: [swift-evolution] guard let x = x

> On Oct 28, 2016, at 4:45 PM, Erica Sadun via swift-evolution > wrote: > > >> On Oct 28, 2016, at 5:00 PM, Huon Wilson > > wrote: >> >> >>> On Oct 28, 2016, at 15:34, Erica Sadun via swift-evolution >>>

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt

> On Oct 19, 2016, at 8:13 AM, Guoye Zhang via swift-evolution > wrote: > > >> 在 2016年10月19日，07:10，Jeremy Pereira 写道： >> >> >>> On 18 Oct 2016, at 19:17, Guoye Zhang via swift-evolution >>> wrote: >>>

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt

Part of the beauty of how optionals are implemented in Swift is that the compiler doesn’t have to do any magic w.r.t. optionals besides a bit of syntactic sugar (`T?` -> `Optional`, `if let x` -> `if let case .some(x)`, auto-boxing when necessary, etc.). - I strongly dislike the idea of

Re: [swift-evolution] [Proposal] Enums with stored properties

> On Oct 12, 2016, at 12:25 PM, Charles Srstka <cocoa...@charlessoft.com> wrote: > >> On Oct 12, 2016, at 12:32 PM, Kevin Nattinger via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> or more like

Re: [swift-evolution] [Proposal] Enums with stored properties

As long as I can use the syntax in Braeden's example, I don't really care how it's implemented, as sugar for some ugly getters or actual stored values. > On Oct 12, 2016, at 04:52, Rien via swift-evolution > wrote: > > I read Braeden’s example such that this

Re: [swift-evolution] [Proposal] Enums with stored properties

I would be amenable to that IF we can skip the `.rawValue`, which is, IMO, ugly and repetitive. > On Oct 10, 2016, at 11:54 AM, J.E. Schotsman via swift-evolution > wrote: > > >> On 10 Oct 2016, at 15:46,Mateusz Malczak wrote: >> >> t a good illustration of what I

Re: [swift-evolution] [Proposal] Enums with stored properties

t;> an enum with no cases? Why artificially separate the two concepts when >> they’re clearly one and the same? >> >> ~Robert Widmann >> >>> On Oct 10, 2016, at 2:24 PM, Kevin Nattinger via swift-evolution >>> <swift-evolution@swift.org <mailto:

Re: [swift-evolution] [Proposal] Enums with stored properties

nd the same? > > ~Robert Widmann > >> On Oct 10, 2016, at 2:24 PM, Kevin Nattinger via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I agree wholeheartedly. An enum case should be a compile-time constant.

Re: [swift-evolution] [Proposal] Enums with stored properties

I agree wholeheartedly. An enum case should be a compile-time constant. IMO, “enums” with associated values should properly be a separate entity, called “union” as that’s essentially what they are. > On Oct 10, 2016, at 10:31 AM, Kenny Leung via swift-evolution >

Re: [swift-evolution] Fwd: Propagating Optionals

> On Oct 7, 2016, at 2:56 PM, Trans via swift-evolution > wrote: > > Just discovered that none of my replies made it to the mailing list. > Doesn't it bug others that the default reply is to the author and not > the list? > > > -- Forwarded message

Re: [swift-evolution] Add something like [unowned self] syntax for passing instance methods into closure parameters without creating retain cycles

> On Sep 13, 2016, at 10:29 AM, Benjamin Spratling via swift-evolution > wrote: > > Well, then also add an unowned convenience. > But I’ve never been handed a story from UX that said, “As a user, when I > want the app to crash.” > Using weak, the compiler can

Re: [swift-evolution] Type-annotated throws

+1 from me. I’m usually highly defensive about types, so the more the compiler can guarantee the better. > On Aug 26, 2016, at 9:01 AM, Nur Ismail via swift-evolution > wrote: > > Hi, > > Sounds like checked exceptions of Java with a similar syntax. With Java you

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

I agree, true is definitely the expected behavior. In particular, it seems absurd to me that `a.hasPrefix(b)` and `a.hasSuffix(b)` could be false when `a == b` is true. > On Jul 18, 2016, at 10:36 AM, Chris Denter via swift-evolution > wrote: > > Hello – > >

Re: [swift-evolution] Extending declaration scope to condition for `repeat { } while ()`

I would love this behavior, I ran into a case just a week or two ago where I was wishing for this behavior. That said, I’m not sure whether it would be possible / feasible for the compiler. And it’s additive so it will have to wait for after Swift 3 is released. > On Jul 18, 2016, at 10:52

Re: [swift-evolution] [Pitch] Remove type inference for associated types

> On Jun 30, 2016, at 10:28 AM, Douglas Gregor via swift-evolution > wrote: > >> >> On Jun 30, 2016, at 9:55 AM, David Hart via swift-evolution >> wrote: >> >> I don't see that as confusing. In a conforming type, he compiler is looking

Re: [swift-evolution] Optionals and nil in Switch statement

nal type 'String?' not >> unwrapped; did you mean to use '!' or '?'? >> case "foo": print("case foo") >> ^ >> ! >> Odd error, but at least it suggests it’s an issue with optionaity. >> >> >>> On Jun 28, 201

Re: [swift-evolution] Optionals and nil in Switch statement

8:6: error: value of optional type 'String?' not unwrapped; > did you mean to use '!' or '?'? > case "foo": print("case foo") > ^ > ! > Odd error, but at least it suggests it’s an issue with optionaity. > > >> On Jun 28, 2016, at 9

Re: [swift-evolution] Optionals and nil in Switch statement

! Odd error, but at least it suggests it’s an issue with optionaity. > On Jun 28, 2016, at 9:27 AM, Nevin Brackett-Rozinsky > <nevin.brackettrozin...@gmail.com> wrote: > > Does `case "text"?` work? > > > On Tuesday, June 28, 2016, Kevin Nattinger vi

Re: [swift-evolution] Optionals and nil in Switch statement

Case .none: Case .some("string"): > On Jun 28, 2016, at 06:40, Lucas Jordan via swift-evolution > wrote: > > Forgive me if this was/is discussed already, I am new to the process here > > (code is attached as a playground too) > > > > Sometimes when I am

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> On Jun 21, 2016, at 10:03 AM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0102: Remove @noreturn attribute and introduce an empty > NoReturn type" begins now and runs through June 27. The proposal is available >

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 7, 2016, at 12:49 PM, Michael Peternell via swift-evolution > wrote: > >> >> Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution >> : >> >>> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution >>>

Re: [swift-evolution] Ad hoc enums / options

Definitely an interesting idea, and I like it, but how would this be used from Objective C? > On May 31, 2016, at 9:16 AM, Erica Sadun via swift-evolution > wrote: > > Here's a function signature from some code from today: > > func scaleAndCropImage( > image:

Re: [swift-evolution] [Idea] Switch Statement with Optional Binding

You can do it today (2.2 and 3.0-master) like this: switch cityIDs["Paris"] { case let .Some(parisCityID) where 0..<10 ~= parisCityID: print("Paris city ID: \(parisCityID)") default: break } > On May 27, 2016, at 1:58 AM, Natthan Leong via swift-evolution >

Re: [swift-evolution] Proposal: Automatic initializer generation

Discussed last month https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014890.html And (linked from that thread) last year http://article.gmane.org/gmane.comp.lang.swift.evolution/727 I think it’s a good idea, but discussion seems to have just petered out without a formal