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

I have given out a proposal about it: Compensate for the inconsistency of @NSCopying's behavior. Please give it some reviews. Thanks. Best, Torin On Tue, Jan 31, 2017 at 2:34 PM +0800, "Torin Kwok via swift-evolution" wrote: Thanks Doug, I’m writing a proposal about it. - Torin

Re: [swift-evolution] The lack of namespaces is leading people astray

I have been known to mimic namespaces as well, however now that SPM is here, I no longer see a need for it. Still, I won’t object to it. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On

Re: [swift-evolution] Default Generic Arguments

Hah, did I really do that :( I completely missed the fact that `let foo: Optional = 42` is supported at the moment. I've been programming in Swift in day zero, but never really used such syntax. I'll update the PR, thanks for your feedback. ons. 1. feb. 2017 kl. 00.05 skrev Xiaodi Wu : > I have

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

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 mailing list has one important advantage over a web interface: most of my reading happens

Re: [swift-evolution] The lack of namespaces is leading people astray

> On Jan 30, 2017, at 5:55 AM, Tuur Anton via swift-evolution > wrote: > > The lack of namespaces is making people create all kinds of "design patterns". > > struct API { > static let endpoint = "http://example.com/api " > } > > Here is an "improvement" to the abov

Re: [swift-evolution] The lack of namespaces is leading people astray

I remain a fan of adding 'namespace' to the language. In the meantime I'll continue using the enum static member approach. But I would love to have something semantically cleaner. > El ene. 30, 2017, a las 3:09 PM, Robert Widmann via swift-evolution > escribió: > > I submitted a proposal wi

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

On Tue, Jan 31, 2017 at 10:15 PM, Dave Abrahams wrote: > > on Tue Jan 31 2017, Xiaodi Wu wrote: > > > On Tue, Jan 31, 2017 at 2:53 PM, Max Moiseev wrote: > > > >> Hi Brent, > >> > >> Thanks a lot for your suggestions! After having discussed them with > Dave, > >> we came up with the following d

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

on Tue Jan 31 2017, Xiaodi Wu wrote: > On Tue, Jan 31, 2017 at 2:53 PM, Max Moiseev wrote: > >> Hi Brent, >> >> Thanks a lot for your suggestions! After having discussed them with Dave, >> we came up with the following design that I personally like a lot. >> >> enum Overflowing { case .withOver

Re: [swift-evolution] Strings in Swift 4

on Tue Jan 31 2017, Xiaodi Wu wrote: > But that's not getting to the biggest hitch with your proposal. If > subscript were lenient, then `arr[lenient: 42...]` would also have to give > you a result even if `arr.count == 21`. > > This is not at all what Dave Abrahams was proposing, though (unless

Re: [swift-evolution] Strings in Swift 4

Sent from my iPad > On Jan 31, 2017, at 7:28 PM, Xiaodi Wu wrote: > >> On Tue, Jan 31, 2017 at 7:08 PM, Matthew Johnson >> wrote: >> >>> On Jan 31, 2017, at 6:54 PM, Xiaodi Wu wrote: >>> On Tue, Jan 31, 2017 at 6:40 PM, Matthew Johnson wrote: > On Jan 31, 2017, at 6:

Re: [swift-evolution] Strings in Swift 4

On Tue, Jan 31, 2017 at 7:08 PM, Matthew Johnson wrote: > > On Jan 31, 2017, at 6:54 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 6:40 PM, Matthew Johnson > wrote: > >> >> On Jan 31, 2017, at 6:15 PM, Xiaodi Wu wrote: >> >> On Tue, Jan 31, 2017 at 6:09 PM, Matthew Johnson >> wrote: >> >>>

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 6:54 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 6:40 PM, Matthew Johnson > wrote: > >> On Jan 31, 2017, at 6:15 PM, Xiaodi Wu > > wrote: >> >> On Tue, Jan 31, 2017 at 6:09 PM, Matthew Johnson >

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 6:15 PM, Jaden Geller wrote: > > >> On Jan 31, 2017, at 4:09 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Jan 31, 2017, at 5:35 PM, Xiaodi Wu via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>>

Re: [swift-evolution] Strings in Swift 4

On Tue, Jan 31, 2017 at 6:40 PM, Matthew Johnson wrote: > > On Jan 31, 2017, at 6:15 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 6:09 PM, Matthew Johnson > wrote: > >> >> On Jan 31, 2017, at 5:35 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> On Tue, Jan 31,

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 6:15 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 6:09 PM, Matthew Johnson > wrote: > >> On Jan 31, 2017, at 5:35 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Tue, Jan 31, 2017 at 5:28 PM, Dav

Re: [swift-evolution] Strings in Swift 4

On Tue, Jan 31, 2017 at 6:27 PM, Jaden Geller wrote: > > On Jan 31, 2017, at 4:20 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 6:15 PM, Jaden Geller > wrote: > >> >> On Jan 31, 2017, at 4:09 PM, Matthew Johnson via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> On Jan 31, 2

Re: [swift-evolution] Strings in Swift 4

On Tue, Jan 31, 2017 at 5:58 PM, Matthew Johnson wrote: > > On Jan 31, 2017, at 5:20 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 5:04 PM, Matthew Johnson > wrote: > >> >> I think it’s fair to say that we get to decide on the semantics of >> postfix `…`. “a range with no upper bound” is ve

Re: [swift-evolution] Strings in Swift 4

On Tue, Jan 31, 2017 at 6:15 PM, Jaden Geller wrote: > > On Jan 31, 2017, at 4:09 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Jan 31, 2017, at 5:35 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Tue, Jan 31, 2017 at 5:28 P

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 4:20 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 6:15 PM, Jaden Geller > wrote: > >> On Jan 31, 2017, at 4:09 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Jan 31, 2017, at 5:35 PM,

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 4:15 PM, Xiaodi Wu via swift-evolution > wrote: > > We don't have partially applied functions doubling as function calls with > default arguments. I think this best summarizes my problem with simultaneously treating `0…` as a partially specified range (waiting for anoth

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 4:09 PM, Matthew Johnson via swift-evolution > wrote: > > >> On Jan 31, 2017, at 5:35 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Tue, Jan 31, 2017 at 5:28 PM, David Sweeris > > wrote: >> >>> On Ja

Re: [swift-evolution] Strings in Swift 4

On Tue, Jan 31, 2017 at 6:09 PM, Matthew Johnson wrote: > > On Jan 31, 2017, at 5:35 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Tue, Jan 31, 2017 at 5:28 PM, David Sweeris > wrote: > >> >> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu wrote: >> >> On Tue, Jan 31, 20

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 5:35 PM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Jan 31, 2017 at 5:28 PM, David Sweeris > wrote: > >> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu > > wrote: >> >> On Tue, Jan 31, 2017 at 3:36 PM, David Sweeri

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 5:20 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 5:04 PM, Matthew Johnson > wrote: > > I think it’s fair to say that we get to decide on the semantics of postfix > `…`. “a range with no upper bound” is very reasonable, but wouldn’t an

Re: [swift-evolution] Removing enumerated?

> On Jan 31, 2017, at 12:46 PM, Ben Cohen via swift-evolution > wrote: > >> // apply alternating view background colors >> for (i, view) in views.enumerated() { >> view.backgroundColor = i % 2 ? bgColor1 : bgColor2 >> } >> > > This is an interesting one because it highlights something els

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

> On 31 Jan 2017, at 20:53, Max Moiseev via swift-evolution > wrote: > > Hi Brent, > > Thanks a lot for your suggestions! After having discussed them with Dave, we > came up with the following design that I personally like a lot. > > enum Overflowing { case .withOverflow } > enum FullWidth {

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 3:36 PM, David Sweeris via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > On Jan 31, 2017, at 11:32, Jaden Geller via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> I think that is

Re: [swift-evolution] Strings in Swift 4

On Tue, Jan 31, 2017 at 5:28 PM, David Sweeris wrote: > > On Jan 31, 2017, at 2:04 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 3:36 PM, David Sweeris via swift-evolution evolut...@swift.org> wrote: > >> >> On Jan 31, 2017, at 11:32, Jaden Geller via swift-evolution < >> swift-evolution@swi

Re: [swift-evolution] Removing enumerated?

+1000 to all of this! > On Jan 31, 2017, at 11:16 AM, Ben Cohen via swift-evolution > wrote: > > I think whether enumerated() is justified as a method on Sequence is one > example of a wider question which definitely needs some discussion, which is: > where should the standard library draw th

Re: [swift-evolution] Strings in Swift 4

On Tue, Jan 31, 2017 at 5:04 PM, Matthew Johnson wrote: > > I think it’s fair to say that we get to decide on the semantics of postfix > `…`. “a range with no upper bound” is very reasonable, but wouldn’t > another reasonable semantics be “all the rest”, meaning that there *is* an > upper bound

Re: [swift-evolution] Default Generic Arguments

I have concerns about these revisions. It seems you've entirely rejected all the options that Alexis has laid out very clearly, and instead you've come up with your own rules which are backwards-incompatible with Swift 3. For instance, the rule "No type inference will happen in type declarations"

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 4:04 PM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Jan 31, 2017 at 3:36 PM, David Sweeris via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > On Jan 31, 2017, at 11:32, Jaden Geller via swift-evolution > mailto:swift-evolution@swift.org>> wrote:

Re: [swift-evolution] Removing enumerated?

On Tue, Jan 31, 2017 at 1:16 PM, Ben Cohen via swift-evolution < swift-evolution@swift.org> wrote: > I think whether enumerated() is justified as a method on Sequence is one > example of a wider question which definitely needs some discussion, which > is: where should the standard library draw the

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

On Tue, Jan 31, 2017 at 2:53 PM, Max Moiseev wrote: > Hi Brent, > > Thanks a lot for your suggestions! After having discussed them with Dave, > we came up with the following design that I personally like a lot. > > enum Overflowing { case .withOverflow } > enum FullWidth { case .fullWidth } > > p

Re: [swift-evolution] Strings in Swift 4

On Tue, Jan 31, 2017 at 3:36 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > On Jan 31, 2017, at 11:32, Jaden Geller via swift-evolution < > swift-evolution@swift.org> wrote: > > I think that is perfectly reasonable, but then it seems weird to be able > to iterate ove

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 11:32, Jaden Geller via swift-evolution > wrote: > > I think that is perfectly reasonable, but then it seems weird to be able to > iterate over it (with no upper bound) independently of a collection). It > would surprise me if > ``` > for x in arr[arr.startIndex…] { prin

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

Cute. Reminds me of C++ STL's struct tags: http://en.cppreference. com/w/cpp/utility/piecewise_construct_t http://en.cppreference.com/w/cpp/iterator/iterator_tags On Tue, Jan 31, 2017 at 12:53 PM, Max Moiseev via swift-evolution < swift-evolution@swift.org> wrote: > Hi Brent, > > Thanks a lot for

Re: [swift-evolution] Strings in Swift 4

on Tue Jan 31 2017, Jaden Geller wrote: On Jan 30, 2017, at 11:35 AM, Dave Abrahams via swift-evolution wrote: Why should that be out-of-bounds? Whether it is out-of-bounds would depend on what items is. If it's an array, that should be equivalent to let

Re: [swift-evolution] Removing enumerated?

> On Jan 31, 2017, at 2:46 PM, Ben Cohen wrote: > >> >> On Jan 31, 2017, at 12:18 PM, Matthew Johnson > > wrote: >> >>> >>> On Jan 31, 2017, at 1:16 PM, Ben Cohen via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> I think whether enumera

Re: [swift-evolution] Default Generic Arguments

I updated the proposal with the things we discussed so far. Have to do some more polishing, but feel free to throw your critique of what I have so far. On Sat, Jan 28, 2017 at 1:32 AM, Xiaodi Wu wrote: > Oh, it's precisely my confidence that a good error message can be devised > which makes me p

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

Hi Brent, Thanks a lot for your suggestions! After having discussed them with Dave, we came up with the following design that I personally like a lot. enum Overflowing { case .withOverflow } enum FullWidth { case .fullWidth } protocol FixedWidthInteger { func adding(_ other: Self, _: Overflow

Re: [swift-evolution] Removing enumerated?

> On Jan 31, 2017, at 12:18 PM, Matthew Johnson wrote: > >> >> On Jan 31, 2017, at 1:16 PM, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I think whether enumerated() is justified as a method on Sequence is one >> example of a wider question which definitel

Re: [swift-evolution] Initializers

> On Jan 31, 2017, at 3:13 PM, Victor Petrescu > wrote: > @John McCall The expense at runtime issue of course. The fact that I need to > add one more line would never bother me enough to bother a few hundreds ppl > in turn :). Are you under the impression that the compiler is unable to inline

Re: [swift-evolution] Removing enumerated?

> On Jan 31, 2017, at 1:16 PM, Ben Cohen via swift-evolution > wrote: > > I think whether enumerated() is justified as a method on Sequence is one > example of a wider question which definitely needs some discussion, which is: > where should the standard library draw the line in providing con

Re: [swift-evolution] Initializers

@John McCall The expense at runtime issue of course. The fact that I need to add one more line would never bother me enough to bother a few hundreds ppl in turn :). On Tue, Jan 31, 2017 at 9:51 PM, John McCall wrote: > On Jan 28, 2017, at 1:07 PM, Victor Petrescu via swift-evolution < > swift-ev

Re: [swift-evolution] Initializers

> On Jan 28, 2017, at 1:07 PM, Victor Petrescu via swift-evolution > wrote: > Hello, > > My name is Victor, been a developer (C, delphi, php, java, js) for the last > 10 years or so and lately I had the chance to try swift. I have a > suggestion/question regarding initializers. > > Sidenote:

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 11:26 AM, Dave Abrahams wrote: > > > on Mon Jan 30 2017, Jaden Geller wrote: > >>> On Jan 30, 2017, at 11:35 AM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> Why should that be out-of-bounds? Whether it is out-of-bounds would >>> depend on what items is. If

Re: [swift-evolution] Strings in Swift 4

on Mon Jan 30 2017, Jaden Geller wrote: >> On Jan 30, 2017, at 11:35 AM, Dave Abrahams via swift-evolution >> wrote: >> >> Why should that be out-of-bounds? Whether it is out-of-bounds would >> depend on what items is. If it's an array, that should be equivalent to >> >> let x = items[it

Re: [swift-evolution] Removing enumerated?

I think whether enumerated() is justified as a method on Sequence is one example of a wider question which definitely needs some discussion, which is: where should the standard library draw the line in providing convenience functions that can easily be composed from other functions in the std li

Re: [swift-evolution] Strings in Swift 4

on Mon Jan 30 2017, Olivier Tardieu wrote: > Thanks for the clarifications. > More comments below. > > dabrah...@apple.com wrote on 01/24/2017 05:50:59 PM: > >> Maybe it wasn't clear from the document, but the intention is that >> String would be able to use any model of Unicode as a backing sto

Re: [swift-evolution] [Proposal] Add Array binary search to the standard library

on Mon Jan 30 2017, Nate Cook wrote: >> On Jan 30, 2017, at 2:47 AM, Alexey Komnin via swift-evolution >> wrote: >> >> Hello to everyone. >> >> Let me put my two cents. > >> I didn’t want the SortedArray to conform to MutableCollection or even RandomAccessCollection as I felt it w

Re: [swift-evolution] [Proposal] Add Array binary search to the standard library

on Mon Jan 30 2017, Alexey Komnin wrote: > Hello to everyone. > > Let me put my two cents. > >>> I didn’t want the SortedArray to conform to MutableCollection or >>> even RandomAccessCollection as I felt it was not needed just to >>> support binary search and prevent re-sorting. >> >> You are ri

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

on Mon Jan 30 2017, Brent Royal-Gordon wrote: >> On Jan 30, 2017, at 11:25 AM, Dave Abrahams via swift-evolution >> wrote: >> >>> I mean that `OptionSet.RawValue` currently has to conform to >>> `BitwiseOperations`, >> >> Actually it doesn't. You just have to implement these yourself in th

Re: [swift-evolution] Removing enumerated?

I'm still a fan of that indexed() proposal... On Tue, Jan 31, 2017 at 8:52 AM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > On Jan 31, 2017, at 10:46 AM, Chris Eidhof wrote: > > I agree that it's very useful. I use it regularly. The documentation isn't > that unclear,

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

+ swift-build-dev To take a step back here, there are two problems I see in this space: 1) Building unnecessary test-only stuff. Say you have a package A which depends on a package B. B might declare a library, a test module, and some auxiliary target that's only needed by the tests. Today, if

Re: [swift-evolution] [Review] SE-0150 Package Manager Support for branches

> On Jan 30, 2017, at 11:43 PM, Martin Waitz wrote: > > Hi Boris, > >> Am 31.01.2017 um 03:48 schrieb Rick Ballard > >: >> >>> >>> On Jan 25, 2017, at 11:06 PM, Martin Waitz via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> OK, you are righ

Re: [swift-evolution] Warn about unused Optional.some(())

> > On Jan 31, 2017, at 8:47 AM, Alex Hoppen wrote: > > Amendment to the history of the bug after I had a look at the bug reports > again: SR-1895 explicitly asked that > > let s: String? = "hi" > s.map {print($0)} This is the anti-pattern we try to discourage. FYI. > should not produce any

Re: [swift-evolution] Removing enumerated?

> On Jan 31, 2017, at 10:46 AM, Chris Eidhof wrote: > > I agree that it's very useful. I use it regularly. The documentation isn't > that unclear, imo. To me, the underlying problem isn't enumerated. I think > the underlying cause is that collections aren't indexed with zero based > indices.i

Re: [swift-evolution] Warn about unused Optional.some(())

Amendment to the history of the bug after I had a look at the bug reports again: SR-1895 explicitly asked that let s: String? = "hi" s.map {print($0)} should not produce any warnings while it did so during beta 1. – Alex > On 31 Jan 2017, at 09:07, Ale

Re: [swift-evolution] Removing enumerated?

I agree that it's very useful. I use it regularly. The documentation isn't that unclear, imo. To me, the underlying problem isn't enumerated. I think the underlying cause is that collections aren't indexed with zero based indices.if you don't understand this (which is the case for many experienced

Re: [swift-evolution] Removing enumerated?

In practical usage, I rarely use enumerated() - and almost every time I do use it, I end up refactoring 20 minutes later to not use it. Maybe that's just me, though. I imagine this isn’t helpful feedback. :P But perhaps we (or I) need to understand what it’s being used for or if there’s a differ

Re: [swift-evolution] Removing enumerated?

I totally sympathize with users being confused. It's an interesting idea to move it to Array only. The thing is, it does make sense (and wouldn't be confusing) to enumerate a dictionary or set. Moreover, the behavior is _exactly_ what it says on the tin: when you enumerate something in real life,

Re: [swift-evolution] Removing enumerated?

> On Jan 31, 2017, at 10:36 AM, Xiaodi Wu via swift-evolution > wrote: > > I totally sympathize with users being confused. It's an interesting idea to > move it to Array only. > > The thing is, it does make sense (and wouldn't be confusing) to enumerate a > dictionary or set. Moreover, the b

Re: [swift-evolution] Warn about unused Optional.some(())

> On 31 Jan 2017, at 09:07, Alex Hoppen via swift-evolution > wrote: > > This was a deliberate change between Swift 3 beta 1 and beta 2 after a friend > of mine pointed the following inconsistency out to me: > > struct Foo { > func bar() {} > } > let foo: Foo? = Foo() > foo?.bar() // Does no

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

It’s (a) the inverse operation of doubleWidthMultiply. (b) an important building block for fast “small bignum arithmetic” (2-16 ish words). If you have this operation, it’s easy to build the divide that does DoubleWidth / DoubleWidth. (c) the widest divide operation that maps reasonably cleanly

Re: [swift-evolution] Warn about unused Optional.some(())

Good to know the history. If I were to fix the inconsistency, I'd add the warning to optional chaining instead. Deliberately make the compiler give us *less* information for esthetic reasons feels wrong to me. As I mentioned in the original email, this has cost us a few unnoticed bad patterns

Re: [swift-evolution] Removing enumerated?

On 31/01/2017 16:19, Ole Begemann via swift-evolution wrote: Here are three previous discussion about this topic: 1) December 2015: [Idea] Add an (Index,Element) sequence to CollectionType https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004561.html and https://lists.sw

Re: [swift-evolution] Removing enumerated?

On 31/01/2017 15:24, Chris Eidhof via swift-evolution wrote: There are a couple of things that keep coming up, and a couple of mistakes that I see people making over and over again. One of them is that in almost every workshop, there's someone who thinks that `enumerated()` returns a list of (ind

Re: [swift-evolution] Strings in Swift 4

If I understand correctly, `1...` is not a Range but a RangeExpression which should not conform to Sequence and would need to be provided with a value for its open end to turn it into a Range. Subscript would provide the last valid index in your first example and for your second example you wou

Re: [swift-evolution] Removing enumerated?

> On Jan 31, 2017, at 3:24 PM, Chris Eidhof via swift-evolution > wrote: > > Hey everyone, > > I've organized a number of Swift workshops over the last two years. There are > a couple of things that keep coming up, and a couple of mistakes that I see > people making over and over again. One

[swift-evolution] Removing enumerated?

Hey everyone, I've organized a number of Swift workshops over the last two years. There are a couple of things that keep coming up, and a couple of mistakes that I see people making over and over again. One of them is that in almost every workshop, there's someone who thinks that `enumerated()` re

Re: [swift-evolution] Generalized Existentials / Type Erasers

Hi Chris, The topic has been heavily discussed last year, culminating into a massing proposal by Austin Zheng: https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md#nested-typealias-existential

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

…rather, the remainder will fit in width min(X, Y) Nevin On Tuesday, January 31, 2017, Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > What, exactly, is the intended purpose of doubleWidthDivide? > > I ask because, outside of degenerate cases, a quotient and remainder will >

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

What, exactly, is the intended purpose of doubleWidthDivide? I ask because, outside of degenerate cases, a quotient and remainder will fit in the same size type as the operands. So widthX / widthY will have quotient that fits in width X, and remainder that fits in width Y. In general, we cannot

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

Afaics the motivation has been explained in detail, but actually, you even can declare such a variable as long as it has its own scope: class Test { func f(i: Int) { print(i) } func g() { let f = 1 // hey, works! print(f)

Re: [swift-evolution] Initializers

I also thought at most of the issues presented before making the suggestion. Let me adress each one (in the order of how I see their importance) and explain my point of view: 1. Most inportant - safety: As Robert Widmann (and others) pointed out swift is safe by default. And I love that about swif

Re: [swift-evolution] Strings in Swift 4

While an unbounded range doesn't need an endIndex to conform to Sequence, conformance would let you iterate over it. If someone were to iterate over it, and, for example, get the numbers [5, 6, 7, 8], one could take that to mean that those numbers are part of the sequence. Based on this, users

Re: [swift-evolution] Warn about unused Optional.some(())

Makes sense now. I remove my point about removing that fix. Optional chaining is much more useful to have behaving as expected. > On 31 Jan 2017, at 10:07, Alex Hoppen via swift-evolution > wrote: > > This was a deliberate change between Swift 3 beta 1 and beta 2 after a friend > of mine poin

Re: [swift-evolution] Annotation of Warnings/Errors

> One of the biggest issues that I saw while teaching Swift to newbies (most > had not programmed before) is confusion based on the early warnings/errors > that swift/xcode gives you as they type. What would happen is that they > would type a variable, and it would say… “You haven’t used this v

Re: [swift-evolution] Warn about unused Optional.some(())

> I think we should remove the special treatment so that code in the example > above would generate a warning about `()?` being unused. Users can silence it > manually by assigning the result to `_`. Imho Swift already uses warnings excessively, and giving Optional more significance than Void

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

> It seams like there is discussion to be had, comparing these models: > > [A] functions have simple names, and arguments have labeled tuple type > model > [B] model where we strictly require the labels for referring to n-ary > functions (e.g. "insert(cell:, into:)" instead of "inser

[swift-evolution] Generalized Existentials / Type Erasers

Hi swift-evolution, I was wondering if anything more detailed has been written about generalized existentials / type erasers. I noticed that AnyCollection only delegates a number of methods to its wrapped value, but often doesn't. For example, all the conditionally inherited items aren't being del

Re: [swift-evolution] Warn about unused Optional.some(())

This was a deliberate change between Swift 3 beta 1 and beta 2 after a friend of mine pointed the following inconsistency out to me: struct Foo { func bar() {} } let foo: Foo? = Foo() foo?.bar() // Does not create a warning true ? foo?.bar() : foo?.bar() // expression of type '()?' is unused

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

> On 31 Jan 2017, at 01:59, Joe Groff via swift-evolution > wrote: > > To be honest, I would say that there's no "reason" for this, except as > lingering effects of our early "functions have simple names, and arguments > have labeled tuple type" model. If we had originally implemented the lan

Re: [swift-evolution] The lack of namespaces is leading people astray

+1 On 31 January 2017 at 11:32, Russ Bishop via swift-evolution < swift-evolution@swift.org> wrote: > > On Jan 30, 2017, at 5:55 AM, Tuur Anton via swift-evolution < > swift-evolution@swift.org> wrote: > > The lack of namespaces is making people create all kinds of "design > patterns". > > > What

[swift-evolution] Proposal to improve C pointer type import

Hi swift-evolution, For the last few weeks, I've been working on introducing some Swift in a pure-C codebase. While the Clang importer makes the process quite smooth, there are still some rough edges. Here is a (lengthy) proposal resulting from that experience. Rendered version: https://gist.