[swift-evolution] final class performance

Somewhere I read that we should always write "final class" where possible, as it is more performant. Is this really the case, especially for non-library modules? Can't the compiler infer whether a class has no subclasses when compiling? Writing "final" just for performance reasons feels wrong.

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

What are the actual use-cases where people have needed destructive iterators? Every time I have thought I wanted it, I ended up wanting multi-pass later. For example, I had a sequence of random numbers, but ended up having to build a random hash instead so I could reliably re-create that

Re: [swift-evolution] Stdlib closure argument labels and parameter names

I did not pay a lot of attention to this renaming because I thought the trailing closure syntax would shield me from labels. But I forgot that in if/for/while statements, I’m going to be forced to use them. In those cases, I’d prefer more succinct labels. I added some comments inline where I

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

Do we lose the ability to create a signed integer from an unsigned bit pattern? Is there a way to get an optional initializer that returns `nil` if the operand can't be represented? What is the cost of heterogeneous comparison? Félix > Le 22 juin 2016 à 22:42:00, David Waite via

Re: [swift-evolution] Revisiting SE-0041 Names

> On Jun 22, 2016, at 19:35, Dmitri Gribenko wrote: > >> On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris wrote: >> That's a really interesting idea. Is "Syntax" a placeholder, or is that the >> intended name? > > It is the best name we could come up

Re: [swift-evolution] Partial list of open Swift 3 design topics

> - Bridge NSRange to “Range?” I don’t think I can handle writing a proposal for this one, but I’d die for it. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

On Wed, Jun 22, 2016 at 10:24 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md > > Hello Swift Community, > > The review of SE-0077: "Improved operator declarations"

Re: [swift-evolution] [Review] SE-0103: Make non-escaping closures the default

>* What is your evaluation of the proposal? +1. It's a positive change. It makes un-annotated code safer, and it moves the annotation to the case where one needs to think about captures as opposed to annotating the case where one doesn't have to think about captures. >* Is the problem

Re: [swift-evolution] Revisiting SE-0041 Names

On Thu, Jun 23, 2016 at 2:00 AM, Xiaodi Wu wrote: > On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution > wrote: >> >> >> > On Jun 22, 2016, at 19:35, Dmitri Gribenko wrote: >> > >> >> On Wed, Jun 22, 2016 at

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0077: Improved operator declarations

Good news for me! I will surely submit a pull request today. - Anton 2016-06-23 7:56 GMT+03:00 Chris Lattner : > > On Jun 22, 2016, at 8:24 PM, Joe Groff wrote: > > Proposal link: >

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

A *strong* -1. This is actually one of the features of Swift which feels most Swift-y™ to me. This is a simple and obvious construct. If we do find confusion (which seems to go away once the feature is explained), we should rename as opposed to remove this feature… but honestly I don’t see

Re: [swift-evolution] Revisiting SE-0041 Names

On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jun 22, 2016, at 19:35, Dmitri Gribenko wrote: > > > >> On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris > wrote: > >> That's a really

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

I agree that the colon-separated syntax looks cleaner. However, I agree with Xiaodi about the stronger/weaker terms being less clear (if only because I associate those terms with memory management in Swift, not operator precedence). My personal preference would be for something like

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

> On 22 Jun 2016, at 17:27, Brandon Knope wrote: > > Of course \ is not needed a lot but when it is, *it is inconvenient for > *some* people*. I am not making this up. You can cite several other users > from this very thread. That’s the point. Convenient key stroke sequences

Re: [swift-evolution] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `Any<P1, P2>`

Regards LM (From mobile) > On Jun 22, 2016, at 8:04 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0095: Replace `protocol` syntax with `Any`" > begins now and runs through June 27. The proposal is

Re: [swift-evolution] Revisiting SE-0041 Names

On Thu, Jun 23, 2016 at 4:34 AM, Dmitri Gribenko wrote: > On Thu, Jun 23, 2016 at 2:00 AM, Xiaodi Wu wrote: > > On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution > > wrote: > >> > >> > >> > On Jun 22, 2016,

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

(First time using a mailing list; I hope this message ends up in the correct thread) This is a topic that comes up regularly on the Swift evolution mailing list and off it. After reading through all the respective threads again, there seem to be the following two camps: Arguments made for

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

1. I've revised the proposal to mostly meet the recommendations. https://github.com/Anton3/swift-evolution/blob/master/proposals/0077- operator-precedence.md 2. My reaction to the rationale: precedencegroup Foo {   associativity: left   strongerThan: Bar   weakerThan: Bas } I agree with

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

Please find the related proposal which was formed after the long discussion in the list: https://github.com/luish/swift-evolution/blob/proposal-lenient-collection-subscripts/proposals/-more-lenient-collections-subscripts.md Here is the pull request on the swift-evolution repo:

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

> Please find the related proposal which was formed after the long discussion > in the list: > > https://github.com/luish/swift-evolution/blob/proposal-lenient-collection-subscripts/proposals/-more-lenient-collections-subscripts.md > >

Re: [swift-evolution] Revisiting SE-0041 Names

I like how your suggestion reads. It will namespace all literal convertibles while also reading more clearly on what conforming to the protocol implies. I now understand the intent of the Syntax namespace however I think you suggested naming would be better. -Shawn On Wed, Jun 22, 2016 at 11:26

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

> The review of "SE-0105: Removing Where Clauses from For-In Loops" begins now > and runs through June 29. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.md > * What is your evaluation of the

[swift-evolution] [Proposal Draft] Literal Syntax Protocols

I have completed a draft of a proposal to move the `*LiteralConvertible` protocols into a `Syntax` namespace as suggested by the standard library team. The draft can be found here: https://gist.github.com/anandabits/99dad2305d310874bd613b72b14eee56

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

Ross O'Brien via swift-evolution writes: > The naming suggestion: why not simply 'precedes' and 'succeeds'? This avoids the conjoined words problem. Then you're just writing 'Multiplication { succeeds: Exponentiation, precedes: Addition }'. I still believe that `above`

[swift-evolution] Shorthand unwrap proposal

I was wondering if people would be open to adding an unwrap method to the Optional type, I already have a method like this which shortens code for me. So this: let myReallyLongOptionalName: String? = "Hey" if let string = myReallyLongOptionalName { doSomethingWith(string) } Could become"

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

My only feedback at the moment is that “Syntax” seems like a weird name. This is all about literals, right? So why not use: Literal.Integer Literal.Float Literal.String etc. l8r Sean > On Jun 23, 2016, at 10:31 AM, Matthew Johnson via swift-evolution > wrote: >

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

On 23.06.2016 0:21, Erica Sadun via swift-evolution wrote: On Jun 14, 2016, at 8:16 PM, Xiaodi Wu via swift-evolution > wrote: As you will see from earlier messages, the confused user is both quite real and *is* on this list. Nor,

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

* What is your evaluation of the proposal? -1. 'where' in 'for-in' loop is very handy and clear construction, it is similar to well-known 'WHERE' clause in SQL which acts the same way : it filters records, not returning just first found record. 'where'/'Where()' in LINQ in C# works

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

On 23.06.2016 15:48, Andreas Ley wrote: Please find the related proposal which was formed after the long discussion in the list: https://github.com/luish/swift-evolution/blob/proposal-lenient-collection-subscripts/proposals/-more-lenient-collections-subscripts.md Thanks; I have seen

Re: [swift-evolution] Shorthand unwrap proposal

There was a proposal not long ago floating around that there could be if and guard that would allow something like: guard myReallyLongOptionalName! else { return } /// Now myReallyLongOptionalName is guaranteed to be nonnull -- OR -- if myReallyLongOptionalName! {

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

Sent from my iPad > On Jun 23, 2016, at 10:39 AM, Sean Heber wrote: > > My only feedback at the moment is that “Syntax” seems like a weird name. This name was suggested by the standard library team. I believe the intent is to place all syntax-supporting protocols in it.

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

* What is your evaluation of the proposal? -1. The proposal suggest removing a useful feature. The arguments presented in the proposal do not warrant introducing another breaking change into the language. I found the "where" clause in for-in loops to be clean and elegant. It does

[swift-evolution] operator or wrapper for NSLocalizedString

Dear community I think NSLocalizedString is little old. Mostly knows what is this. Sure, everyone of swift user can make operator or some kind convenient functions. But always, native supports will be better choice. I suggest operator or wrapper for NSLocalizedString like #selector(…) Ex)

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

I am -0.5 on removing the where clause. I will note that removing it now - given the appearing limited usage - shouldn't cause a large disruption to most users. It may allow us time to think more about it and things related to it since it can be added back at a later point without breaking swift 3

Re: [swift-evolution] Swift *less* safe than C for imported API that uses opaque struct pointers

> On Jun 22, 2016, at 12:58, Joe Groff via swift-evolution > wrote: > >> >> On Jun 22, 2016, at 11:20 AM, Timothy J. Wood via swift-evolution >> wrote: >> >> >> Currently, APIs that get imported with COpaquePointer make Swift *less*

Re: [swift-evolution] Prohibit invisible characters in identifier names

> On 21 Jun 2016, at 20:15, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Jun 21, 2016 at 1:16 PM, Joe Groff > wrote: > Any discussion about this ought to start from UAX #31, the Unicode > consortium's

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

If we chose something other than strongerThan and weakerThan, I would really like to see something like evaluateBefore, evaluateAfter foundBefore, foundAfter lookupBefore, lookupAfter On Thu, Jun 23, 2016 at 11:32 AM, Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote: > Ross

Re: [swift-evolution] Shorthand unwrap proposal

On Thu, Jun 23, 2016 at 8:36 AM, James Campbell via swift-evolution wrote: > I was wondering if people would be open to adding an unwrap method to the > Optional type, I already have a method like this which shortens code for > me. > > So this: > > let

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> On Jun 23, 2016, at 2:23 AM, Félix Cloutier via swift-evolution > wrote: > > What is the cost of heterogeneous comparison? Smaller-than-wordsize comparisons will fall out for free in most cases. For word size and larger types, there’s one extra test in some

Re: [swift-evolution] Prohibit invisible characters in identifier names

I’m no unicode expert, but this sounds like the way to go to me. l8r Sean > On Jun 23, 2016, at 11:17 AM, João Pinheiro via swift-evolution > wrote: > > >> On 21 Jun 2016, at 20:15, Xiaodi Wu via swift-evolution >> wrote: >> >> On

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

> "..*most* people don’t expect.." could you prove this please? I should have written “most people I know” or “the people I work with". > Especially if they know a little of C language or other language that don't > allow to use wrong indexes for arrays. Maybe that’s the point: They don’t. And

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] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> > * What is your evaluation of the proposal? -1 The first “problem” given in the motivation is "As an orthogonal attribute of function types, its interaction must be specified with every other aspect of function types” Errr, well yes, of course. Why is it a problem that orthogonal

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

> On Jun 23, 2016, at 8:18 AM, Anton Zhilin via swift-evolution > wrote: > > 1. I've revised the proposal to mostly meet the recommendations. Thanks continuing to push this forward! I’m really looking forward to this change and hope the revision is met with

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

> On Jun 23, 2016, at 4:52 PM, Andreas Ley via swift-evolution > wrote: > >> "..*most* people don’t expect.." could you prove this please? > > I should have written “most people I know” or “the people I work with". > >> Especially if they know a little of C

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

* What is your evaluation of the proposal? +1 * Is the problem being addressed significant enough to warrant a change to Swift? It's a small change, but it would improve readability a little. * Does this proposal fit well with the feel and direction of Swift? Yes, e.g. when using

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

I've got another suggestion for the bike shedding, and a question. The naming suggestion: why not simply 'precedes' and 'succeeds'? This avoids the conjoined words problem. Then you're just writing 'Multiplication { succeeds: Exponentiation, precedes: Addition }'. The question: this syntax lets

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

Hi David, > In addition to the technical review, I would like to point out that the > definition of Arithmetic appears to be missing some underscores in > add/adding/subtract/subtracting Thank you! I’ll fix it. > For Integer, does the presence of signBit indicate an expectation that signed >

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

> On Jun 23, 2016, at 11:43 AM, Nate Cook wrote: > > I like the namespace-based approach to group these protocols together and I'm > very happy to see some clarification happening in this group of protocols. > However, I don't think the proposed new names communicate what

Re: [swift-evolution] Shorthand unwrap proposal

> On Jun 23, 2016, at 8:45 PM, Tim Vermeulen via swift-evolution > wrote: > > I would love to be able to do something like > > doSomething(with: myOptional?) This actually looks good to me, though if I were a newcomer to the language, it would be really cryptic.

Re: [swift-evolution] Shorthand unwrap proposal

But ! still suggests force unwrapping, while ? suggests safe unwrapping. Why not use a question mark? > It was in the previous proposal and suggested that you are not trying to > shadow the previous variable, but trying to unwrap it - and it acts as > unwrapped from there on. > > > > On Jun

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

-1 for all the reasons already mentioned. Although, if we end up accepting this anyway, FWIW I'd prefer "DoesNotReturn" or "NeverReturns" over "NoReturn" or "Never". They both read better to me, and their imperative names help make it clearer that something is different. - Dave Sweeris > On

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

Hi Remy, > I would also like to know why bit shifting and bit-wise and, or and xor > operations are limited to FixedWidthInteger. I would think that a > variable-length integer would be able to handle these operations in a > predictable way consistent with the protocol. Wouldn't it? The

Re: [swift-evolution] Shorthand unwrap proposal

I wasn’t suggesting we allow the use of optional values as function parameters and just do nothing if the parameter is indeed optional. Optional parameters can be perfectly valid. I was talking about a syntax where we can put ? behind an optional parameter to signify that we don’t want to

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

> On 23 juin 2016, at 09:32, Anton Zhilin via swift-evolution > wrote: > > Ross O'Brien via swift-evolution writes: > >> The naming suggestion: why not simply 'precedes' and 'succeeds'? This > avoids the conjoined words problem. Then you're

Re: [swift-evolution] Shorthand unwrap proposal

You can also do something like that is ur code today: extension Optional { func unwrap (_ h: T -> ()) { switch self { case .Some(let w): if let t = w as? T { h(t) } break default: break; } } } s1.unwrap { (str:String) in

Re: [swift-evolution] Prohibit invisible characters in identifier names

On Thu, Jun 23, 2016 at 12:56 PM, Xiaodi Wu wrote: > On Thu, Jun 23, 2016 at 12:41 PM, João Pinheiro > wrote: > >> There are two different issues here, individual character normalisation >> and identifier canonicalisation. NFC handles character

Re: [swift-evolution] Shorthand unwrap proposal

Why with the exclamation mark? It suggests you’re force unwrapping something. > > On Jun 23, 2016, at 8:45 PM, Tim Vermeulen via > > swift-evolutionwrote: > > > > I would love to be able to do something like > > > > doSomething(with: myOptional?) > This actually

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

Hi Xiaodi, > Q2: I do not understand the comment explaining signBitIndex. I thought I > understood what it does from the name, but the comment says it's not the > right name. So what is signBitIndex? The name is good but the way it is implemented in the prototype currently is NOT what the

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

> * What is your evaluation of the proposal? -1. I don't think this is really a big deal, but I find where clauses on for loops to be very elegant, and I'm not convinced by any of the arguments for why they should go away. I'm especially not convinced by the argument over the behavior

Re: [swift-evolution] Shorthand unwrap proposal

Awesome, cheers guys! *___* *James⎥Head of Trolls* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 23 June 2016 at 17:26, Dmitri Gribenko

Re: [swift-evolution] Shorthand unwrap proposal

Regards (From mobile) > On Jun 23, 2016, at 8:51 PM, Charlie Monroe via swift-evolution > wrote: > > >> On Jun 23, 2016, at 8:45 PM, Tim Vermeulen via swift-evolution >> wrote: >> >> I would love to be able to do something like >> >>

Re: [swift-evolution] Shorthand unwrap proposal

Sure, the exact syntax is a matter of discussion, I just wasn't that much of favor of the very short doSomething(with: myOptional?) - it looks like a great idea, making the code really short - on the other hand the question mark is next to the variable, but the method's execution is optional -

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

-1 An important goal in Swift is “clarity at the point of use,” it appears in the API Design Guidelines as one of the fundamentals, but also pervades the design of the Swift language itself. I think that removing the `where` clause from Swift’s `for` loops will reduce clarity of intent for

Re: [swift-evolution] Prohibit invisible characters in identifier names

On Thu, Jun 23, 2016 at 2:29 PM, João Pinheiro wrote: > > I think we're using terminology differently here. What you call > "character normalization" is what I'm calling canonicalization. NFC is > described in UAX #15 as "canonical decomposition followed by canonical >

Re: [swift-evolution] Prohibit invisible characters in identifier names

> On 23 Jun 2016, at 20:43, Xiaodi Wu wrote: > That's cool, although my preferred solution would be more closely aligned > with UAX #31: overtly disallow the glyphs in Table 4 (instead of ignoring > them) except in the specific scenarios for ZWJ and ZWNJ identified in UAX

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

I must note that this `where` does not belong to `case`. Compare: for case x? where x < 10 in y { ... } for x in y where x < 10 { ... } First syntax is standard and won't go away. Second syntax is for-in specific, and is considered inconsistent. * What is your evaluation of the proposal? +1,

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

+1. I have not encountered this issue myself but it looks like something that would cause a lot of head scratching if I had. It is also something that I am unlikely to remember immediately if I run into it in the future. The current behavior appears broken to me. It will be great to have it

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

This is certainly surprisingly behavior to me! +1 l8r Sean > On Jun 23, 2016, at 2:53 PM, Slava Pestov via swift-evolution > wrote: > > Consistent formal type for 'self' in class methods > > • Proposal: SE- > • Author: Slava Pestov > •

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

A separate point I would make, aside from my previous long-winded comment about clarity, is that the “confusion of use” in this proposal has already been corrected by SE-0099 which has removed `where` clauses from optional-binding and case-conditions. Scott

[swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

Consistent formal type for 'self' in class methods Proposal: SE- Author: Slava Pestov Status: Awaiting review Review manager: TBD

Re: [swift-evolution] Prohibit invisible characters in identifier names

> On Jun 23, 2016, at 3:54 PM, João Pinheiro via swift-evolution > wrote: > >> On 23 Jun 2016, at 20:43, Xiaodi Wu > > wrote: >> That's cool, although my preferred solution would be more closely aligned >> with UAX

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

Sent from my iPad > On Jun 23, 2016, at 3:12 PM, Slava Pestov wrote: > > Great to hear some feedback so quickly, especially about something so mundane. You caught me at the right time I guess. :) This kind of thing is only mundane until your code doesn't behave as you

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

> On Jun 23, 2016, at 1:30 PM, Slava Pestov wrote: > > >> On Jun 23, 2016, at 1:27 PM, Xiaodi Wu > > wrote: >> >> When you mention the difficulty of an alternative, is that to say that it's >> not feasible for the

Re: [swift-evolution] Shorthand unwrap proposal

and before someone points it out, yes the follow does work, but i just thought the long form was easier to understand extension Optional { func unwrap (_ h: T -> ()) { if let t = self as? T { h(t) } } } Regards (From mobile) > On Jun 23, 2016, at 8:19 PM, L. Mihalkovic

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

Hi Félix, > Do we lose the ability to create a signed integer from an unsigned bit > pattern? As I mentioned in one of the earlier replies, the proposal does not contain the full API diff. `init(bitPattern:)` is very useful and will remain. However, I don’t think it should be added to any of

Re: [swift-evolution] Prohibit invisible characters in identifier names

> I think we're using terminology differently here. What you call "character > normalization" is what I'm calling canonicalization. NFC is described in UAX > #15 as "canonical decomposition followed by canonical composition" and I'm > just using the word "canonicalization" because it's shorter.

Re: [swift-evolution] Shorthand unwrap proposal

Dmitri pointed out a few posts ago that Swift already has this. let opInt: Int? = nil opInt.map {$0.toIntMax()} //Evaluates to nil Are you talking about something different? - Dave Sweeris > On Jun 23, 2016, at 2:04 PM, Charlie Monroe via swift-evolution > wrote: >

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

• Renaming all methods which operate on more than one element at the beginning/end to use "prefix" or "suffix", not "first" or "last" +1 • Renaming `index(of:/where:)` to `earliestIndex(…)` and `first(where:)` to `earliest(where:)` -1, because `index` is considered state-of-art. `first` does

[swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

Simpler interpretation of a reference to a generic type with no arguments Proposal: SE- Author: Slava Pestov Status: Awaiting review Review

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

I’m going to register a -1 on this proposal. I appreciate the work that went into it, but I just don’t think any advantages for the developer community as a whole weight enough to warrant the change. > On Jun 23, 2016, at 4:41 AM, Jeremy Pereira via swift-evolution >

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

When you mention the difficulty of an alternative, is that to say that it's not feasible for the GenericBox in the last example to be resolved as GenericBox? From an end-user point of view, that seems to be the most sensible behavior. On Thu, Jun 23, 2016 at 15:14 Slava Pestov via swift-evolution

Re: [swift-evolution] Prohibit invisible characters in identifier names

+1 on this. Josh Wisenbaker’s example says enough. Yikes! > On Jun 23, 2016, at 3:18 PM, David Sweeris via swift-evolution > wrote: > > +1 > I didn't even know there were any invisible characters until this thread came > up. > > - Dave Sweeris > > On Jun 23, 2016,

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

> On Jun 23, 2016, at 1:27 PM, Xiaodi Wu wrote: > > When you mention the difficulty of an alternative, is that to say that it's > not feasible for the GenericBox in the last example to be resolved as > GenericBox? From an end-user point of view, that seems to be the most

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

> On Jun 23, 2016, at 1:39 PM, Xiaodi Wu wrote: > > Good to know. I absolutely agree that the gains to be had here wouldn't be > worth a one-off hack. If people are strongly (or even mildly) opposed to removing this rule, we can give some thought to a more general

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> On Jun 23, 2016, at 12:39 AM, David Hart wrote: >> - for test in removeFirstTests.filter({ $0.numberToRemove == 1 }) { >> + for test in removeFirstTests.filter( >> +suchThat: { $0.numberToRemove == 1 } >> >> The difference between `filter` and `forEach` is

Re: [swift-evolution] [Proposal] Remove Boolean

It does abstract over DarwinBoolean as well, but this still seems reasonable to me. The most common cases to encounter ObjCBool and DarwinBoolean are out-parameters (which you are usually setting rather than reading, and they will remain BooleanLiteralConvertible) and imported struct fields

Re: [swift-evolution] Prohibit invisible characters in identifier names

Indeed, the case shown in Josh's example was the motivation for this thread and will be solved by the proposal. The current discussion has been around whether it should be solved by ignoring invisible characters or prohibiting them and explicitly highlighting them as an error. I originally

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

Hi Nicola, > For these reasons, I think it would make sense to explicitly request that > the remainder operation never traps, and remove the overflow variants. It will still trap when you divide by 0. But in that case falling back to the same generic overflow logic is not the best idea. I agree

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> On Jun 23, 2016, at 14:38, Nicola Salmoria via swift-evolution > wrote: > > Max Moiseev via swift-evolution writes: > >>> For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under > what situations would >> you have an overflow?

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

I’m against removing “where" from “for/in”. I use it in my code and I think it aids readability quite a bit. In the example: for x in theArray where x % 2 == 1 { print (x) } I think it’s artificially confusing because the print is on the same line. If we break the line we see the “where” at the

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

Quick (semi) related question: any particular reason for .Type to be a contextual kwd rather than defined on a protocol? (No concrete def for metatypes?) Regards LM (From mobile) > On Jun 23, 2016, at 11:02 PM, Andrew Trick via swift-evolution > wrote: > > >>> On

[swift-evolution] [Draft] UnsafeRawPointer API

I sent two RFC's for this proposal over the past couple months (see Early swift-evolution threads). High-level feedback was fairly light. This version is a final draft, as I expect it to go through the review process next week. There is a lot more explanation and detail in this proposal now,

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

Great to hear some feedback so quickly, especially about something so mundane. I suspect the real reason it doesn’t work this way now is that ‘Self’ is not fully plumbed through. In particular, if a closure captures the ‘Self’ type, IRGen does not properly codegen it, causing compile-time or

Re: [swift-evolution] Prohibit invisible characters in identifier names

+1 I didn't even know there were any invisible characters until this thread came up. - Dave Sweeris > On Jun 23, 2016, at 15:13, Xiaodi Wu via swift-evolution > wrote: > >> On Thu, Jun 23, 2016 at 2:54 PM, João Pinheiro wrote: >> >> > On 23

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> * What is your evaluation of the proposal? +1 The protocols are well thought out and make total sense to me. I only have a miner gripe with the naming of: func nthWord(n: Int) -> UInt Which reads very weird. Why not: func word(at: Int) -> UInt > * Is the problem being

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

Most of your proposal look great to me! Comments inline: > On 23 Jun 2016, at 09:19, Brent Royal-Gordon via swift-evolution > > wrote: > > As previously threatened mentioned, I've written a draft proposal to fix a > number of naming

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

I like this draft. Quickly: - “removing” sounds more destructive than “skipping”, so I’d lean towards using “skipping”. I would be happy with either, though. - there are two different labels for predicates (where and while). “where” is probably the better label. (some previous discussion had

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`

Regards LM (From mobile) > On Jun 24, 2016, at 5:55 AM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md > ] > > I’ve gone on record before as against this syntax,

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

On Fri, Jun 24, 2016 at 12:45 AM, Guillaume Lessard via swift-evolution < swift-evolution@swift.org> wrote: > I like this draft. Quickly: > > - “removing” sounds more destructive than “skipping”, so I’d lean towards > using “skipping”. I would be happy with either, though. > - there are two

  1   2   >