Re: [swift-evolution] Reduce with inout

> On Jan 21, 2017, at 12:37 AM, Russ Bishop wrote: > >> On Jan 16, 2017, at 9:43 AM, Charles Srstka via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: > >> I don’t even know how long it actually takes to finish this test, because >> the last time I did this I eventually got sick

Re: [swift-evolution] Method dispatching issue with subclasses implementing Equatable protocol.

This is very interesting and all Swift developers will need to be aware of it, if it isn’t a bug. One thing that I think is a little worrying is that if, rather than the == operator, you had a CustomEquatable protocol which defined the equal(to:) function, that function would be dynamically dis

Re: [swift-evolution] Reduce with inout

> >> On 18 Jan 2017, at 12:45, Georgios Moschovitis >> wrote: >> >>> That’s what I thought also until just now, but then why wouldn’t you just >>> use a for … in loop? >> >> the former gives a hint about what someFunction (and the for-loop) is doing. > > > Whereas the latter explicitly lay

Re: [swift-evolution] Reduce with inout

> On Jan 16, 2017, at 9:43 AM, Charles Srstka via swift-evolution > wrote: > I don’t even know how long it actually takes to finish this test, because the > last time I did this I eventually got sick of waiting and killed the process. > So, I don’t know quite how many orders of magnitude slow

Re: [swift-evolution] Assigning to 'self' in protocol extensions

> On Jan 19, 2017, at 11:11 PM, Slava Pestov via swift-evolution > wrote: > > >> On Jan 19, 2017, at 10:52 PM, rintaro ishizaki via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> From the perspective of the caller, I think, this behavior is >> counterintuitive because we

Re: [swift-evolution] Strings in Swift 4

> On Jan 20, 2017, at 2:45 PM, Dave Abrahams via swift-evolution > wrote: > > on Fri Jan 20 2017, Joe Groff wrote: > >> Jordan points out that the generalized slicing syntax stomps on '...x' >> and 'x...', which would be somewhat obvious candidates for variadic >> splatting if that ever become

Re: [swift-evolution] Proposal: Remove the "fallthrough" keyword

> On Jan 20, 2017, at 12:45 PM, Joe Groff via swift-evolution > wrote: > >> >> On Jan 20, 2017, at 12:22 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Sat Dec 05 2015, jgr...@apple.com (Joe Groff) wrote: >> >> >> We should just call a spade a spade and spell that "goto" ;-)

Re: [swift-evolution] Strings in Swift 4

I want to start by saying great work, Ben and Dave. I know you've put a lot of time into this (and humored me in several Apple-internal discussions) and what's here looks like a great overhaul of String, balancing several tricky constraints. I do want to record some comments on specific parts of th

Re: [swift-evolution] Strings in Swift 4

> On Jan 20, 2017, at 2:58 PM, Saagar Jha via swift-evolution > wrote: > > Sorry if I wasn’t clear; I’m looking for indexing using Int, instead of using > formIndex. Question: why do you think integer indices are so desirable? Integer indexing is simple, but also encourages anti-patterns (t

Re: [swift-evolution] Strings in Swift 4

> On Jan 20, 2017, at 5:15 PM, Ben Cohen via swift-evolution > wrote: > > >> On Jan 20, 2017, at 3:29 PM, Jaden Geller via swift-evolution >> wrote: >> >> Wouldn’t `x[…]` be more consistent with these other syntaxes? >> > > Maybe (though are those extra characters really telling you much?

Re: [swift-evolution] Strings in Swift 4

> On Jan 20, 2017, at 6:11 PM, Joe Groff wrote: > > >> On Jan 20, 2017, at 5:15 PM, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Jan 20, 2017, at 3:29 PM, Jaden Geller via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Would

Re: [swift-evolution] Compiler Optimization of Optional-returning Functions followed by '!'

> On 20 Jan 2017, at 07:41, Russ Bishop via swift-evolution > wrote: > > >> On Jan 19, 2017, at 4:17 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> For those times when you _don't_ know how many elements there are, don't >> care, and for some reason can

Re: [swift-evolution] Strings in Swift 4

> On Jan 20, 2017, at 3:29 PM, Jaden Geller via swift-evolution > wrote: > > Wouldn’t `x[…]` be more consistent with these other syntaxes? > Maybe (though are those extra characters really telling you much?). But you can’t write that in Swift – you’d need a 0-argument operator. (Or a […] p

Re: [swift-evolution] Strings in Swift 4

on Fri Jan 20 2017, Jonathan Hull wrote: > Perhaps we could separate the proposal from the manifesto, and then > use the manifesto to collect future plans as well in all of the areas > around string processing (which could later be broken off into smaller > proposals), similar to how the Generic

Re: [swift-evolution] Strings in Swift 4

>> >> Are the backing representations for String also the same types that can be >> exposed statically (as in the mentioned `NFCNormalizedUTF16String`)? > > Roughly. I think we want at least the following backing representations for > String: > > 1. The two compressed representations used by

Re: [swift-evolution] [Pitch] Refactor Metatypes

> On Jan 20, 2017, at 12:37 PM, Anton Zhilin via swift-evolution > wrote: > > Could someone tell if the proposal fits Phase 1? Seeing SE-0148—which doesn't > contain any ABI-breaking changes—being reviewed for Phase 1, I'm not sure > about anything. > The PR should either be labeled "out of s

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

> Le 20 janv. 2017 à 22:55, Howard Lovatt via swift-evolution > a écrit : > > In Java there is a hierarchy of errors, the idea is that you catch at > different severities. It isn't particularly well implemented in Java with a > weird hierarchy and errors strangely classified and poor naming.

Re: [swift-evolution] Strings in Swift 4

on Fri Jan 20 2017, Joe Groff wrote: >> On Jan 20, 2017, at 8:28 AM, Dave Abrahams via swift-evolution > wrote: >> >> >> >> > >> >> >> >> >>> On Jan 20, 2017, at 5:48 AM, Jonathan Hull >> > wrote: >>> >>> Thanks for all the hard work! >>> >>> Still digesting, bu

Re: [swift-evolution] Strings in Swift 4

> On Jan 20, 2017, at 2:57 PM, Dave Abrahams via swift-evolution > wrote: > >> The “Empty Subscript” >> >> Empty subscript seems weird. IMO, it’s because of the asymmetry >> between subscripts and computed properties. I would favour a model >> which unifies computed properties and subscripts (

Re: [swift-evolution] Strings in Swift 4

Perhaps we could separate the proposal from the manifesto, and then use the manifesto to collect future plans as well in all of the areas around string processing (which could later be broken off into smaller proposals), similar to how the Generics manifesto has been working? My main concern wi

Re: [swift-evolution] Strings in Swift 4

>> * The talk about implicit conversions between Substring and String bums me >> out, even though I see the importance of it in this context and know that >> it outweighs the alternatives. Given that the Swift team seems to prefer >> explicit to implicit conversions in general, I would hope that i

Re: [swift-evolution] Strings in Swift 4

on Fri Jan 20 2017, Karl Wagner wrote: > Very nice improvements overall! > >> To ease the pain of type mismatches, Substring should be a subtype >> of String in the same way that Int is a subtype of >> Optional. This would give users an implicit conversion from >> Substring to String, as well as

Re: [swift-evolution] Strings in Swift 4

on Fri Jan 20 2017, Tony Allevato wrote: > I'm excited to see this taking shape. Thanks for all the hard work putting > this together! > > A few random thoughts I had while reading it: > > * You talk about an integer `codeUnitOffset` property for indexes. Since > the current String implementatio

Re: [swift-evolution] Strings in Swift 4

on Fri Jan 20 2017, Joe Groff wrote: > Jordan points out that the generalized slicing syntax stomps on '...x' > and 'x...', which would be somewhat obvious candidates for variadic > splatting if that ever becomes a thing. Now, variadics are a much more > esoteric feature and slicing is much more

Re: [swift-evolution] Strings in Swift 4

This looks really great to me. I am not an expert in this area so I don’t have a lot of detailed comments. That said, it looks like it will significantly improve the string handling experience of app developers, including better bridging to the APIs we work with every day. I did notice one pa

Re: [swift-evolution] Strings in Swift 4

on Fri Jan 20 2017, Gwendal Roué wrote: >> One ask - make string interpolation great again? > > I have a dream, that ExpressibleByStringInterpolation would allow to > distinguish literal segments > and embedded inputs. > > Today, the documentation of this protocol [1] says: > > "One cooki

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

In Java there is a hierarchy of errors, the idea is that you catch at different severities. It isn't particularly well implemented in Java with a weird hierarchy and errors strangely classified and poor naming. Despite these glaring shortcoming it does actually work! In Swift this general conce

Re: [swift-evolution] Strings in Swift 4

on Thu Jan 19 2017, Saagar Jha wrote: > Looks pretty good in general from my quick glance–at least, it’s much > better than the current situation. I do have a couple of comments and > questions, which I’ve inlined below. > > Saagar Jha > >> On Jan 19, 2017, at 6:56 PM, Ben Cohen via swift-evolut

Re: [swift-evolution] Proposal: Remove the "fallthrough" keyword

> On Jan 20, 2017, at 12:22 PM, Dave Abrahams via swift-evolution > wrote: > > > on Sat Dec 05 2015, jgr...@apple.com (Joe Groff) wrote: > >>> On Dec 5, 2015, at 10:13 AM, David Owens II wrote: >>> >>> Is there a reason we cannot use labelled case statements? >>> >>>switch some_value {

Re: [swift-evolution] [Pitch] Refactor Metatypes

Could someone tell if the proposal fits Phase 1? Seeing SE-0148—which doesn't contain any ABI-breaking changes—being reviewed for Phase 1, I'm not sure about anything. The PR should either be labeled "out of scope of current release", or merged. Or maybe it contains some fundamental flaws that even

Re: [swift-evolution] Proposal: Remove the "fallthrough" keyword

on Sat Dec 05 2015, jgr...@apple.com (Joe Groff) wrote: >> On Dec 5, 2015, at 10:13 AM, David Owens II wrote: >> >> Is there a reason we cannot use labelled case statements? >> >> switch some_value { >> case .REFINED: >> if !validate(some_value) { return NULL } >> fallt

Re: [swift-evolution] Method dispatching issue with subclasses implementing Equatable protocol.

Ah... we will be missing hiding behind the warm embrace of message passing/dynamic dispatch :P Sent from my iPhone > On 20 Jan 2017, at 19:24, Pierre Monod-Broca via swift-evolution > wrote: > > The way I understand it, it's a bad idea to override == and != (or any infix > operator) for Sub

Re: [swift-evolution] Strings in Swift 4

Syntax-wise, it almost seems like there shouldn’t be a comma after the variable name because then it looks like an argument to a function. What if it was just a space? "now you have \(n radix: 16, width: 2) problems" Anyway, this seems cool. :) l8r Sean > On Jan 20, 2017, at 1:19 PM, J

Re: [swift-evolution] Strings in Swift 4

Very nice improvements overall! > To ease the pain of type mismatches, Substring should be a subtype of String > in the same way that Int is a subtype of Optional. This would give users > an implicit conversion from Substring to String, as well as the usual > implicit conversions such as [Subs

Re: [swift-evolution] Strings in Swift 4

> On Jan 20, 2017, at 8:28 AM, Dave Abrahams via swift-evolution > wrote: > > > > Sent from my iPad > > > > Sent from my iPad >> On Jan 20, 2017, at 5:48 AM, Jonathan Hull > > wrote: >> >> Thanks for all the hard work! >> >> Still digesting, but I definitely suppor

Re: [swift-evolution] Method dispatching issue with subclasses implementing Equatable protocol.

The way I understand it, it's a bad idea to override == and != (or any infix operator) for Sub if Super has them and that's why the default implementation from Equatable only generates !=(Super, Super) and not !=(Sub, Sub) (and there is no ==(Sub, Sub) generated either). And it's a bad idea bec

Re: [swift-evolution] Strings in Swift 4

Jordan points out that the generalized slicing syntax stomps on '...x' and 'x...', which would be somewhat obvious candidates for variadic splatting if that ever becomes a thing. Now, variadics are a much more esoteric feature and slicing is much more important to day-to-day programming, so this

[swift-evolution] [Review] SE-0148 Generic Subscripts

• What is your evaluation of the proposal?  Well written, concise and to the point. +1 on support for default values as well. • Is the problem being addressed significant enough to warrant a change to Swift?  Absolutely, not to mention is part of our Generic Manifesto  https://github.com/app

Re: [swift-evolution] HTML rendering output (was: Strings in Swift 4)

With the current model, I’d make a first pass of this sort of functionality by doing: 1. Define a HtmlEncoded wrapping struct that indicated a value was meant to be safe to output directly, rather than be encoded. This would make encoding safe by default (opt out) 2. HTML content built via stri

Re: [swift-evolution] Strings in Swift 4

> I think the \( … ) is just as readable as ${ … }. Actually, I would have been > OK with \{ … } but I think that ship has sailed because of the existing code > base using \( … ). Totally agree! ___ swift-evolution mailing list swift-evolution@swift.o

Re: [swift-evolution] Strings in Swift 4

> > Which for my preference makes the syntax feel more readable, avoids the > "double ))" in terms of string interpolation termination and function > termination points. And if that's not enough brings the "feel" of the > language to be scriptable in nature common in bash, sh, zsh and co.. > s

Re: [swift-evolution] Strings in Swift 4

> On 20 Jan 2017, at 11:55, Maxim Veksler wrote: > > Please see discussion inline. > > On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira > wrote: > > > On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution > > wrote: > > > > One ask - make string interpolation great again? > > > > Takin

Re: [swift-evolution] [Review] SE-0148 Generic Subscripts

> What is your evaluation of the proposal? +1 > Is the problem being addressed significant enough to warrant a change to > Swift? Yes, generic subscripts are often useful. > Does this proposal fit well with the feel and direction of Swift? It definitely fits with Swift’s aim to be consistent, lo

Re: [swift-evolution] Strings in Swift 4

I'm excited to see this taking shape. Thanks for all the hard work putting this together! A few random thoughts I had while reading it: * You talk about an integer `codeUnitOffset` property for indexes. Since the current String implementation can switch between backing storage of ASCII or UTF-16

Re: [swift-evolution] Strings in Swift 4

> On Jan 20, 2017, at 8:04 AM, Ole Begemann wrote: > >> The downside of having two types is the inconvenience of sometimes having >> a >> `Substring` when you need a `String`, and vice-versa. It is likely this >> would >> be a significantly bigger problem than with `Array` and `ArraySlice`, as >

Re: [swift-evolution] Strings in Swift 4

> One ask - make string interpolation great again? I have a dream, that ExpressibleByStringInterpolation would allow to distinguish literal segments and embedded inputs. Today, the documentation of this protocol [1] says: "One cookie: $\(price), \(number) cookies: $\(price * number)."

Re: [swift-evolution] Strings in Swift 4

> The downside of having two types is the inconvenience of sometimes having > a > `Substring` when you need a `String`, and vice-versa. It is likely this > would > be a significantly bigger problem than with `Array` and `ArraySlice`, as > slicing of `String` is such a common operation. It is especi

Re: [swift-evolution] Strings in Swift 4

Sent from my iPad > On Jan 19, 2017, at 8:20 PM, Xiaodi Wu wrote: > > Clearly too big to digest in one take. Some initial thoughts: > > * Not sure about the wisdom of the ad-hoc Substring : String compiler magic. > It seems that whatever needs overcoming here would be equally relevant for >

Re: [swift-evolution] Strings in Swift 4

Sent from my iPad > On Jan 19, 2017, at 6:07 PM, Ben Cohen wrote: > > The defaults for case-, diacritic-, and width-insensitivity are different for > localized operations than for non-localized operations, so for example a > localized sort should be case-insensitive by default, and a non-local

Re: [swift-evolution] Strings in Swift 4

> On Jan 19, 2017, at 10:42 PM, Jose Cheyo Jimenez wrote: > > I just have one concern about the slice of a string being called Substring. > Why not StringSlice? The word substring can mean so many things, specially in > cocoa. This idea has a lot of merit, as does the option of not giving th

Re: [swift-evolution] Strings in Swift 4

Found it: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021548.html Saagar Jha > On Jan 20, 2017, at 4:10 AM, Charlie Monroe via swift-evolution > wrote: > >> >> On Jan 20, 2017, a

Re: [swift-evolution] Strings in Swift 4

Sent from my iPad > On Jan 19, 2017, at 8:18 PM, Ben Cohen wrote: > > >> On Jan 19, 2017, at 19:38, David Sweeris wrote: >> >> Regarding substrings... Instead of having separate `ArraySlice` and >> `Substring` types, what about having just one type, `Slice`, >> for anything which shares m

Re: [swift-evolution] Strings in Swift 4

Sent from my iPad > On Jan 19, 2017, at 8:13 PM, David Sweeris wrote: > > > > Sent from my iPhone > >> On Jan 19, 2017, at 20:56, Ben Cohen via swift-evolution >> wrote: >> >> Hi all, >> >> Below is our take on a design manifesto for Strings in Swift 4 and beyond. >> >> Probably best rea

Re: [swift-evolution] Strings in Swift 4

extension Unicode { // An example of the option language in declaration context, // with nil defaults indicating unspecified, so defaults can be // driven by the presence/absence of a specific Locale func frobnicated( case caseSensitivity: StringSensitivity? = nil, diacritic diacriticSen

Re: [swift-evolution] Strings in Swift 4

> On Jan 20, 2017, at 2:48 PM, Jonathan Hull via swift-evolution > wrote: > > ... > > • One thing that stood out was the interpolation format syntax, which seemed > a bit convoluted and difficult to parse: >> "Something with leading zeroes: \(x.format(fill: zero, width:8))" > > > Have you c

Re: [swift-evolution] Strings in Swift 4

Thanks for all the hard work! Still digesting, but I definitely support the goal of string processing even better than Perl. Some random thoughts: • I also like the suggestion of implicit conversion from substring slices to strings based on a subtype relationship, since I keep running into tha

Re: [swift-evolution] Strings in Swift 4

> Le 20 janv. 2017 à 05:07, Saagar Jha via swift-evolution > a écrit : > > Looks pretty good in general from my quick glance–at least, it’s much better > than the current situation. I do have a couple of comments and questions, > which I’ve inlined below. > > Saagar Jha > >> … > > Any reas

Re: [swift-evolution] Strings in Swift 4

> On Jan 20, 2017, at 12:55 PM, Maxim Veksler via swift-evolution > wrote: > > Please see discussion inline. > > On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira > mailto:jeremy.j.pere...@googlemail.com>> > wrote: > > > On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution > > mailto:s

Re: [swift-evolution] Strings in Swift 4

Please see discussion inline. On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira < jeremy.j.pere...@googlemail.com> wrote: > > > On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution < > swift-evolution@swift.org> wrote: > > > > One ask - make string interpolation great again? > > > > Taking fr

Re: [swift-evolution] Strings in Swift 4

> On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution > wrote: > > One ask - make string interpolation great again? > > Taking from examples supplied at > https://github.com/apple/swift/blob/master/docs/StringManifesto.md#string-interpolation > > "Column 1: \(n.format(radix:16, width

Re: [swift-evolution] [Review] SE-0148 Generic Subscripts

https://github.com/apple/swift-evolution/blob/master/proposals/0148-generic-subscripts.md > • What is your evaluation of the proposal? +1 Enthousiastic! > • Is the problem being addressed significant enough to warrant a change > to Swift? Yes, because library developers are require

Re: [swift-evolution] [Review] SE-0148 Generic Subscripts

I’m +1 for the proposal. Context, in case it’s useful for anyone: My particular use case for generic subscripts is with my SwiftyUserDefaults library (https://github.com/radex/SwiftyUserDefaults ), which allows users to access user defaults with a s

Re: [swift-evolution] Closures from methods with default args

> On Jan 20, 2017, at 6:07 AM, David Sweeris wrote: > > > On Jan 9, 2017, at 02:13, Charlie Monroe via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> I came across something that I'm not sure it's a bug or by design and if >> it's by design, whether this should be discussed

Re: [swift-evolution] Method dispatching issue with subclasses implementing Equatable protocol.

On Wed, Jan 18, 2017 at 6:58 PM, Tony Allevato wrote: > Ok, this actually does feel a bit strange. The behavior you're seeing > seems to be a consequence of [SE-0091](https://github.com/ > apple/swift-evolution/blob/master/proposals/0091-improving-operators-in- > protocols.md), but it looks like

Re: [swift-evolution] Assigning to 'self' in protocol extensions

> In the specific case of initializers, my opinion here is the opposite in >> fact — I think assigning to ‘self’ should be permitted in all convenience >> initializers, even initializers defined directly classes, without the >> protocol extension trick. Also, we should lower this more efficiently t

Re: [swift-evolution] Assigning to 'self' in protocol extensions

2017-01-20 16:11 GMT+09:00 Slava Pestov : > > Is your proposal to ban calls to such mutating methods on a type that is > known to be a reference type at compile time altogether? This will create > an inconsistency between code that operates on concrete types and code that > operates on generic par