Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Given that these are fairly low-level values with very specialized uses, I definitely agree that they should be somehow namespaced in a way that doesn't cause us to make very common words unusable for our users. Even size(of:) seems more general to me than I'd like. I'd like to see the word

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

e errors out with "expression was too complex to be solved in reasonable time": let value: Int64 = (0x1b << 0) | (0x28 << 7) | (0x79 << 14) | (0x42 << 21) | (0x3b << 28) | (0x56 << 35) | (0x00 << 42) | (0x05 << 49) | (0x26 <<

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

+1. As someone who thought "var x: Int32 = 0" and "var x = Int32(0)" were equivalent, this is very good to know (and very good to fix). I'm starting to wonder now if some of the times I've hit "expression was too complex" errors with large 64-bit multi-term expressions with literals were caused

Re: [swift-evolution] [Proposal] Enum subsets

I like the idea, conceptually—having more set-like semantics for enums sounds like it would open up some interesting possibilities. (And I don't think we should limit ourselves to subsets either. Supersets are also interesting.) Things could get pretty tricky though, so there are a lot of gaps to

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

I like the "from" keyword the best, but I'll take my own stab at a modification: import ModuleA import ModuleB "hello world".(capitalized from ModuleA)() "hello world".(capitalized from ModuleB)() "hello world".(someProperty from ModuleA) "hello world".(someProperty from

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

"Nothing" feels like it collides too much with the concept of a function that returns, but returns nothing (i.e., Void), however. If I read a function declaration from left to right: func foo() -> Nothing I read that as "a function foo that returns nothing". That sounds like a Void function

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need animpl

On Fri, Jun 10, 2016 at 3:03 PM Leonardo Pessoa via swift-evolution < swift-evolution@swift.org> wrote: > The thing with NSUnimplemented was really just a mention and nothing to do > with the issue. > > As for the real issue, the blacklist you mention is formed after parsing > the source. That's

[swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

I was inspired to put together a draft proposal based on an older discussion in the Universal Equality, Hashability, and Comparability thread that recently got necromanced (thanks Mark Sands!). I'm guessing that this would be a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

Thanks for your feedback, Doug! I've addressed some of your concerns inline. On Thu, Jun 9, 2016 at 10:16 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > Proposal link: > > >

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

Big +1. I had similar thoughts a while back when I was writing some C++ or Java code that had boolean arguments, and I found myself hating how non-documenting they were and I would contrive two-valued enums to make call sites look better. Having a crisp clean syntax for this would be fantastic and

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

On Wed, Jun 1, 2016 at 3:02 PM Vladimir.S wrote: > > in other words, we could consider allowing this: > >func foo(bar: (.fit | .fill)) { > > baz(bar: bar) > >} > >func baz(bar: (.fit | .fill | .florp) { ... } > > > > In other words, an ad hoc enum T can

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

I find myself agreeing with the idea that ad hoc enums are to enums as structs are to tuples. Based on that analogy, why should an ad hoc enum *need* a name (autogenerated or otherwise) any more than a tuple needs a name? Would those who dislike ad hoc enums argue that this also shouldn't be

Re: [swift-evolution] [Idea] Allowing definition of custom behaviors for `as` casting

What benefit would this provide that writing them as initializers already doesn't? Writing the first two lines this way seems much clearer from a call-site point of view: let user1 = User(json: ["firstname": "Yaman", "lastname": "JAIOUCH"]) let user2 = User(string: "Yaman JAIOUCH") That aside,

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

On Tue, Jun 21, 2016 at 10:04 AM Chris Lattner 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 here: > > >

Re: [swift-evolution] [Pitch] Allow use of the name "default" for enum cases and function names

lowercasing of enum cases. > > On Fri, Jun 17, 2016 at 15:55 Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > >> Agreed, it sounds like default should be treated as a contextual keyword >> in this case. >> >> It never even occ

Re: [swift-evolution] [PITCH] WatchKit API Design Change to use properties instead of methods to set properties

Doing this would require a larger change in Swift than a single API. WKInterfaceLabel is "one-way" in the sense that those values can be set with setter methods, but there is no API to get the values back. This can't map to properties in Swift as they're implemented today, because a property with

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0105: Removing Where Clauses from For-In Loops

On Wed, Jun 22, 2016 at 9:12 PM Chris Lattner wrote: > Hello Swift community, > > The review of "SE-0105: Removing Where Clauses from For-In Loops" begins > now and runs through June 29. The proposal is available here: > > >

Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

On Fri, Jun 24, 2016 at 11:30 AM Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > On Fri, Jun 24, 2016 at 6:37 AM, William Shipley wrote: > >> On Jun 23, 2016, at 11:04 PM, Xiaodi Wu wrote: >> >> >> Not a practitioner of 80-character line

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

I really like where this proposal is headed. Would this syntax also support constraining associated types based on "inheritability" (for lack of a better word)? For example, a couple times I've hit a situation where I want to express a supertype/subtype relationship. A contrived example:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

gt; swift-evolution@swift.org> wrote: > >> > >> on Tue Apr 26 2016, Chris Lattner <swift-evolution@swift.org> wrote: > >> > >>> On Apr 26, 2016, at 7:34 PM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > > > >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On 2016-04-26 22:32:16 +, Dave Abrahams via swift-evolution said: The main reasons to route through a single generic operator implementation are: * User experience; we want to cut down the number of overloads of any operator to a manageable set, in part because they live in the global

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution < swift-evolution@swift.org> wrote: > > > func isEqual(to other: Self) ->Bool > > > func isLess(than other: Self) ->Bool > > > func isLessThanOrEqual(to other: Self) ->Bool > > > > I'm still not sure why these are methods instead

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

is kept > within the conforming type. > > - Dave Sweeris > > > On Apr 26, 2016, at 9:28 AM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > > On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution < > swift-evolution@swi

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Tue, Apr 26, 2016 at 11:29 AM Nicola Salmoria wrote: > On Tue, Apr 26, 2016 at 8:10 PM, Thorsten Seitz > wrote: > >> See inline. >> >> Am 26.04.2016 um 19:36 schrieb Nicola Salmoria via swift-evolution < >> swift-evolution@swift.org>: >> >> On

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 26, 2016, at 11:42 AM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Apr 26, 2016, at 8:47 AM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > >> That seems like a purely syntactic conce

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Tue, Apr 26, 2016 at 10:36 AM Nicola Salmoria wrote: > On Tue, Apr 26, 2016 at 4:28 PM, Tony Allevato > wrote: > >> On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> > > func

Re: [swift-evolution] [Pitch] 'Double modulo' operator

I've had to write a "true mod" function enough times across different projects (usually for circular buffer indexing or angular arithmetic) that it would absolutely support its inclusion in stdlib (for both integer and floating point types). The `%` operator historically has been implemented as

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

+1 On Mon, May 16, 2016 at 2:07 PM Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what > you'd expect, but does lead to problems when an 'as' expression appears as > part of a comparison: > > 20 as

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Wed, May 18, 2016 at 1:00 PM Nicola Salmoria wrote: > On Wed, May 18, 2016 at 8:03 PM, Tony Allevato > wrote: > >> On Wed, May 18, 2016 at 10:02 AM Nicola Salmoria via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> > * What is

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Wed, May 18, 2016 at 1:37 PM Nicola Salmoria wrote: > On Wed, May 18, 2016 at 10:27 PM, Tony Allevato > wrote: > >> >> What I'm saying is, if you look at the Swift 3 branch of stdlib, global >> operator functions still do not have argument

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Wed, May 18, 2016 at 1:56 PM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > Personally, I find Rust’s approach a bit ugly. And Tony makes a very good > point in the proposal that using words requires us to learn the word > associated with each operator. >

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Wed, May 18, 2016 at 2:20 PM Matthew Johnson wrote: > On May 18, 2016, at 4:06 PM, Tony Allevato wrote: > > On Wed, May 18, 2016 at 1:56 PM Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> Personally, I find Rust’s

Re: [swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!

I strongly prefer that things like properties and variables, even if they start with an acronym or initialism, start lowercase. When writing Objective-C, if I have a property or variable named just "url", I always debate whether I should call it "URL" or "url". This will become even trickier once

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Mon, May 23, 2016 at 9:58 PM Jordan Rose wrote: > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md > ] > > Hi, Tony. Thanks for working on this. I have to say I’m incredibly > concerned with this

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Mon, May 23, 2016 at 9:20 PM David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > > On May 18, 2016, at 18:07, plx via swift-evolution < > swift-evolution@swift.org> wrote: > > > > How hard would it be to e.g. simply allow something like this: > > > > func ==(lhs: T, rhs:

Re: [swift-evolution] [Proposal] Disallow redundant `Any<...>` constructs

What's the behavior if you have something like this: struct Foo { func foo(bar: Any) { ... } } let f = Foo ...? More generally, my fear is that being *too* restrictive about banning redundant types could get you into a situation through generic metaprogramming where you

Re: [swift-evolution] [Discussion] Namespaces

Another use case to consider: code generation. There, namespaces can be vital; they let you isolate code that you may have no real control over (for example, data models that correspond to remote services) from the rest of your code to avoid collisions. In some cases that can be achieved by

Re: [swift-evolution] [Discussion] Namespaces

On Fri, May 20, 2016 at 8:48 AM Matthew Johnson <matt...@anandabits.com> wrote: > On May 20, 2016, at 10:27 AM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > > Another use case to consider: code generation. There, namespaces can be > vital

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

On Tue, May 10, 2016 at 11:53 AM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0084: Allow trailing commas in parameter lists and > tuples" begins now and runs through May 16. The proposal is available here: > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

On Wed, May 11, 2016 at 8:09 AM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > > To summarize the complaints to date: > > * It make code read like errors > * Arrays and dictionaries are different "things" than parameters and > tuples; They are structurally different > *

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

I'm +1 on this. It seems like it would solve the issue of Objective-C APIs losing their protocol conformances on properties/arguments/return values when they're added to a class, like UIView. That always seemed like a major hole in the cross-language support and when writing ObjC libraries I've

Re: [swift-evolution] [Idea] if let value!

While I've sometimes (early on) wished for a shorter-hand syntax for that construct, I've never been able to think of something that I thought was better. I've gotten to the point where I don't particularly mind it anymore. Regarding the exclamation point specifically, seeing one of those in an

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

On Tue, May 10, 2016 at 11:48 AM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0041: Updating Protocol Naming Conventions for > Conversions" begins now and runs through May 16. The proposal is available > here: > > >

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

On 2016-05-10 18:51:29 +, Chris Lattner via swift-evolution said: Hello Swift community, The review of "SE-0081: Move where clause to end of declaration" begins now and runs through May 16. The proposal is available here:

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

On 2016-05-14 16:29:40 +, Haravikk via swift-evolution said: On 14 May 2016, at 16:52, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote: To me, this makes declarations with complex sets of constraints much harder to read, because I have to hunt them down i

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

I think there would be a certain elegance to allowing Boolean type expressions wherever types are currently allowed, so `A & B` being a replacement for `protocol` might look nice, and then extend that to allow concrete types as well. Then, if Swift ever decided to support union types, the

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

+1. I've built APIs before where I wanted a method to take a closure that had multiple arguments, but where I would also like the client to be able to ignore the extra arguments if they didn't need that level of detail, and it would be nice to not require them to acknowledge those extra parameters

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

On Tue, May 17, 2016 at 9:03 PM Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > I'm in favor, with one small concern: > > > Then, the protocol author is responsible for providing a generic global > trampoline operator that is constrained by the protocol type and

Re: [swift-evolution] Pitch: Modify the meaning of IBOutlet to remove the ! from the type

Similarly, a weak reference cannot be non-optional. I would be uncomfortable with an attribute changing that behavior. Having a non-optional field become nil or crash behind the scenes discards the safety of the Swift type system. There are legitimate situations where a class might have unused

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

On Tue, May 17, 2016 at 8:32 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0089: Renaming String.init(_: T)" begins now and runs > through May 23. The proposal is available here: > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

On Wed, May 18, 2016 at 12:10 AM Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > Or should the compiler only allow those two argument labels for unary > operator functions? That feels strange since it's not a restriction present > anywhere else, and it starts to

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Wed, May 18, 2016 at 10:02 AM Nicola Salmoria via swift-evolution < swift-evolution@swift.org> wrote: > > * What is your evaluation of the proposal? > > I'm generally in strong support, having long been a proponent of removing > operators from protocols (the first occurrence was in this

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

Hi Dmitri, thanks for the great feedback. I've updated the pull request < https://github.com/apple/swift-evolution/pull/283>. On Mon, May 2, 2016 at 5:53 PM Dmitri Gribenko <griboz...@gmail.com> wrote: > On Mon, May 2, 2016 at 9:44 AM, Tony Allevato via swift-evolution >

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

On Tue, May 3, 2016 at 10:44 AM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon May 02 2016, Chris Lattner wrote: > > > On May 2, 2016, at 4:59 PM, Xiaodi Wu wrote: > > > > Hmm, a thought going in a slightly different direction: if

[swift-evolution] [Proposal] Improving operator requirements in protocols

I've written a proposal to formalize some of the discussion that was had over in the thread for the `FloatingPoint` protocol proposal regarding improvements to operator requirements in protocols that do not require named methods be added to the protocol and conforming types. Thanks to everyone who

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

On Mon, May 2, 2016 at 1:25 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon May 02 2016, Tony Allevato wrote: > > > Open issue: Class types and inheritance > > > > While this approach works well for value types, these static

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

On Mon, May 2, 2016 at 1:20 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > Tony, thanks for writing this up! > > on Mon May 02 2016, Tony Allevato wrote: > > > Other kinds of operators (prefix, postfix, assignment) > > > > Static operator

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

On Mon, May 2, 2016 at 1:30 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon May 02 2016, Tony Allevato wrote: > > > Acknowledgments > > > > Thanks to Chris Lattner and Dave Abrahams for contributing to the early > > discussions,

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

On Mon, May 2, 2016 at 2:01 PM Xiaodi Wu wrote: > Maybe one minimalist approach could be to have these take two arguments as > though it's an infix operator where one of lhs or rhs is Void: > > T.++(, ()) //postfix > T.++((), ) // prefix This feels a little too much like

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

On Mon, May 2, 2016 at 1:56 PM Dave Abrahams wrote: > > on Mon May 02 2016, Tony Allevato wrote: > > > On Mon, May 2, 2016 at 1:20 PM Dave Abrahams via swift-evolution > > wrote: > > > > How does one distinguish between calls to a static

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

I like this suggestion a lot. Using labels has a nice elegance to it and makes the usage very clear. If we drop the -ing like Chris suggests, it also aligns nicely with the same keywords used to define them. I'm not a parser expert, but this seems like it might be easier to parse than

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

I would also be supportive of removing varargs for now, in favor of a rethought design when generics are completed. In their current form, varargs are fairly limited—because they're mapped onto an array, the argument types must be homogeneous, so either your function can only usefully take a

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:54 AM Dmitri Gribenko via swift-evolution < swift-evolution@swift.org> wrote: > On Fri, Jul 22, 2016 at 8:38 AM, Nevin Brackett-Rozinsky > wrote: > > Excellent point Karl. > > > > In my view, floating point NaN values are really quite

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

I like a lot of this, but the changes to Equatable are where I get stuck. What are the scenarios where areSame is useful *outside* the context of the proposed new Comparable interface? I ask because changing the requirement for Equatable to areSame instead of == seems like a backwards change to

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 2:52 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jul 22 2016, Tony Allevato wrote: > > > I like a lot of this, but the changes to Equatable are where I get stuck. > > What are the scenarios where areSame

Re: [swift-evolution] [Review] SE-0128: Change failable UnicodeScalar initializers to failable

+1. This is an obvious improvement and makes the API safer to use, and aligns with other string APIs (like those that decode UTF-8). On Thu, Jul 21, 2016 at 3:31 PM Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > +1. Sensible change; addresses a real issue; proposed solution

Re: [swift-evolution] End of source-breaking changes for Swift 3

I noticed that while SE-0091 appears to be implemented (from a cursory glance at some of the affected types like Equatable and String), it looks like the named methods are still part of the FloatingPoint protocol and they still use global operators. Is anyone tracking the migration of that

Re: [swift-evolution] [Accepted] SE-0091: Improving operator requirements in protocols

Thanks Chris! I'm happy that the proposal was well-received, and thanks to Doug for the great improvements for revision 2. Related, does the acceptance of this proposal imply the removal of the named methods from FloatingPoint and Arithmetic in favor of static operators, or do we need a separate

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

On Wed, Jul 20, 2016 at 1:14 PM Guillaume Lessard via swift-evolution < swift-evolution@swift.org> wrote: > > > On 20 juil. 2016, at 12:42, Michael Peternell via swift-evolution < > swift-evolution@swift.org> wrote: > > > > +1 > > this should be a bugfix. > > First, NSString’s prefix function

Re: [swift-evolution] [Proposal] Variadics as Attribute

I'm also having trouble getting behind this proposal. IMO, variadics as implemented today in Swift (and in Java) are a subset of the problems that can be solved with variadic generics. They're more limited because you can't today support heterogeneous argument lists without losing static type

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

A deeper problem is that String is already internally inconsistent because of the special case in hasPrefix/Suffix: String("abc").characters.prefix(0) == "" which should imply that "abc".hasPrefix("") == true. The existing implementation of hasPrefix/Suffix inherited from NSString is a bug,

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

On Thu, Jul 21, 2016 at 8:33 AM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The third review of "SE-0117: Allow distinguishing between public access > and public overridability" begins now and runs through July 25. The > proposal is available

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

On Tue, Jul 19, 2016 at 9:00 AM Félix Cloutier wrote: > > Here's one way this could be implemented: if you write `struct Foo: > Equatable` without implementing a `func ==`, the compiler makes one for > you. Done. > I floated a draft proposal a while back that

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

On Tue, Jul 19, 2016 at 9:17 AM Ted F.A. van Gaalen via swift-evolution < swift-evolution@swift.org> wrote: > ok, Dave > > > > to me - strings being collections -, all I see is: > trying to find an empty string within another string: There are (at least) > two ways of treating this: > > 1.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

On Tue, Jul 5, 2016 at 4:11 PM Chris Lattner wrote: > Hello Swift community, > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > >

Re: [swift-evolution] [pitch] remove global sqrt

Agreed. Imagine this: let distance = (x * x + y * y).squareRoot() That reads extremely foreign to me. Why not provide this as a static function that takes Self on the protocol so that conformances can specialize it, and have the protocol-constrained global function sqrt call T.sqrt? On Mon, Jul

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0091: Improving operator requirements in protocols

On Thu, Jul 7, 2016 at 11:37 AM Daniel Resnick via swift-evolution < swift-evolution@swift.org> wrote: > What is your evaluation of the proposal? >> > +1 > > >> Is the problem being addressed significant enough to warrant a change to >> Swift? >> > Yes, the current situation of defining a

Re: [swift-evolution] [Discussion] Can we make `.Type` Hashable?

+1. I've had to do this a couple times and ended up wrapping them in string interpolations, which makes me feel terrible. On Fri, Jul 1, 2016 at 6:26 AM David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > +1 > > On Jul 1, 2016, at 8:20 AM, Adrian Zubarev via swift-evolution <

Re: [swift-evolution] [Review] SE-0109: Remove the Boolean protocol

On Tue, Jun 28, 2016 at 11:44 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of SE-0109 "Remove the Boolean protocol" begins now and runs > through July 4, 2016. The proposal is available here: > > >

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0111: Remove type system significance of function > argument labels" begins now and runs through July 4. The proposal is > available here: > > >

Re: [swift-evolution] !? operator for ternary conditional unwrapping

What you're asking for is already possible (avoiding the optional unwrap) by combining map() on Optional with ??: ``` let name1: String? = "name" print(name1.map { "\"\($0)\"" } ?? "null") // prints "\"name\"" let name2: String? = nil print(name2.map { "\"\($0)\"" } ?? "null") // prints "null"

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Which is another reason we should be auto-deriving Equatable. Couldn't variation generics help here? If someone wanted to capture the whole argument list as a single tuple, we could require that they do it as a parameter pack? It's essentially the inverse of the tuple splat already mentioned in

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

It should already be possible to handle special cases like that since you can reässign self in an initializer. Here's a contrived example; would it allay your performance concerns? ``` struct Foo: ExpressibleByIntegerLiteral { private let value: String private static let zero = Foo("a

Re: [swift-evolution] Testing enum cases with associated values

Conditional conformances doesn't solve enum equality though, because there likely won't be a way to utter "enum Foo : Equatable where " with the generics syntax that's available, and conformance alone wouldn't be able to derive the implementation. It'll require some work on the compiler's part to

Re: [swift-evolution] Support for assertions/preconditions that sometimes fail.

This sounds like a problem that a third-party logging API could handle easily, and there's nothing about Swift's current implementation blocking you or someone else from writing one. It feels like a fairly specialized use case—it's hard to see it being fundamental enough to argue that it be part

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

As a general rule of thumb, changes to the language should not require the use of an IDE in order to return them back to the level of usability that was had before the change. Swift is not a Mac/Xcode-only language, and even on that platform, there are a number of times where I personally find

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

This seems to work for me: ``` class Super: Equatable { let x: Int init(x: Int) { self.x = x } func equals(_ rhs: Super) -> Bool { return x == rhs.x } static func ==(lhs: Super, rhs: Super) -> Bool { return lhs.equals(rhs) } } class Sub: Super

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

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 you're seeing different behavior than what I described in the

Re: [swift-evolution] Removing var keyword in protocol property reqirements

jgr...@apple.com> wrote: > > > On Jan 18, 2017, at 8:41 AM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Personally, I don't feel that the problem is big enough to warrant a > breaking change here. > > > > `var` is the gener

Re: [swift-evolution] Testing enum cases with associated values

FWIW, I'm not convinced that making enum values look like structs with optional properties for the union of all their cases is a good idea. It's certainly not something I would want added to all of my enums by default, and it feels IMO like it's just an awkward hack around the fact that pattern

Re: [swift-evolution] Reduce with inout

On Wed, Jan 18, 2017 at 10:33 AM Guillaume Lessard via swift-evolution < swift-evolution@swift.org> wrote: > > > On 18 janv. 2017, at 10:21, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote: > > > >> On Jan 18, 2017, at 2:11 AM, Chris Eidhof via swift-evolution < >

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

On Thu, Jan 19, 2017 at 1:39 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of SE-0148 “Generic Subscripts" begins now and runs through > January 24, 2017. The proposal is available here: > > >

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

On Thu, Jan 19, 2017 at 2:17 PM Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > Hi all, > > I would like to propose an optimization to the compiler where, when a call > to an optional-returning function is immediately followed by a ‘!’, we > allow the compiler to generate

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Obvious +1. Since enum cases with payloads are essentially static factory functions and you can get references to them just like any other function, those references should follow the same rules as a regular function. On Thu, Jan 19, 2017 at 10:37 AM Daniel Duan via swift-evolution <

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] [Proposal] Replace all Swift comments by end notes.

On Mon, Jan 16, 2017 at 8:38 AM Amir Michail wrote: > > > On Jan 16, 2017, at 10:55 AM, Tony Allevato > wrote: > > > > As a general rule of thumb, changes to the language should not require > the use of an IDE in order to return them back to the level

Re: [swift-evolution] Equatable auto-write func == Proposal

I started on an early-draft proposal for something like this a while back: https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad Most of the discussion in the e-mail thread (I don't have time to fetch the link right now, unfortunately) was around how implicit/explicit such behavior

Re: [swift-evolution] private & fileprivate

I actually feel exactly the opposite of this—personally I thought `private` was fine the way it was when it meant `fileprivate` and I had no real need for `private` as it exists in Swift 3. `fileprivate` is useful because it lets me organize my code in such a way that I divide large types (for

Re: [swift-evolution] Mark protocol methods with their protocol

+1. This is the cleanest proposed solution I've seen to this problem. Like many people, I've started breaking up a lot of my large classes like view controllers that have multiple protocol conformances into separate extensions, and this would let many of those diagnostics fall out naturally. On

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

On Fri, Oct 14, 2016 at 1:00 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" > begins now and runs through October 18. The proposal is available here: > > >

  1   2   3   >