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

Yikes, not only is the email too big for some mail clients, it's too big for the mailing list. Resending with proposal snipped. On Thu, Jun 23, 2016 at 1:24 PM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > Most of your proposal look great to me! Comments inline: > > On 23

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

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] [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

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 23, 2016, at 20:40, John McCall wrote: > >> On Jun 23, 2016, at 6:03 PM, Jordan Rose via swift-evolution >> > wrote: >>> On Jun 15, 2016, at 18:47, Charles Srstka via swift-evolution >>>

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

[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, although when I set out earlier today to

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

Thanks for answering my questions earlier. I like a lot of the changes. Speaking of heterogeneous comparisons again, though, how are comparisons of negative signed integers with unsigned integers handled? Félix > Le 23 juin 2016 à 17:36:14, Max Moiseev via swift-evolution >

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 23, 2016, at 6:03 PM, Jordan Rose via swift-evolution > wrote: >> On Jun 15, 2016, at 18:47, Charles Srstka via swift-evolution >> > wrote: >> >>> On Jun 15, 2016, at 8:36 PM, Robert Widmann

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

Inline Regards (From mobile) > On Jun 23, 2016, at 10:13 PM, Anton Zhilin via swift-evolution > wrote: > > L. Mihalkovic via swift-evolution writes: > >> Has a meta-circular syntax been considered for the precedence group > definitions? Aside

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

> On Jun 23, 2016, at 3:38 PM, Jordan Rose via swift-evolution > wrote: > > 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

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

Maybe something like this? let calendar = Calendar.current() for date in dates where calendar.isDateInToday(date) { //process date only in today } VS. for date in dates { guard calendar.isDateInToday(date) else { continue } } The where keeps the body of the for loop uncluttered

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

> Le 23 juin 2016 à 00:12, Chris Lattner via swift-evolution > a écrit : > > 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-0103: Make non-escaping closures the default

> * What is your evaluation of the proposal? I support it; if escaping and nonescaping are about equally common, but users would never discover a @nonescaping on their own, I think it makes sense to have @escaping instead. However, I'm concerned about migration. Rather than saying that

[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,

[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] [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?

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] [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] 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] 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] [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] [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] [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

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] 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] 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] 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] [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 > •

[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] [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] [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] [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

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] [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] 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

[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] [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

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] [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] 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] 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] [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

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] [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

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] 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

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] [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] 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] 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] [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] [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] [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] 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] [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] [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] 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] 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] [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] 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] [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] [Proposal Draft] Literal Syntax Protocols

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 they need to. The names listed in the "Alternatives Considered" section do a

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

I think this issue is bigger than that. As UAX #31 suggests, the most appropriate approach is canonicalizing identifiers by NFC, with specific treatment of ZWJ and ZWNJ by allowing them in three contexts, which will require thought as to how to implement. Given that there is a specifically

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

> On Jun 23, 2016, at 9:17 AM, João Pinheiro via swift-evolution > wrote: > > >> On 21 Jun 2016, at 20:15, Xiaodi Wu via swift-evolution >> > wrote: >> >> On Tue, Jun 21, 2016 at 1:16 PM, Joe Groff

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

On Jun 23, 2016, at 2:23 AM, Félix Cloutier via swift-evolution wrote: > Is there a way to get an optional initializer that returns `nil` if the > operand can't be represented? That’s in the Arithmetic Protocol in the proposal: /// Initializes to the value of

Re: [swift-evolution] Shorthand unwrap proposal

Here is the thread: http://thread.gmane.org/gmane.comp.lang.swift.evolution/17142 > On Jun 23, 2016, at 6:02 PM, James Campbell wrote: > > Do we know what happened ? > > ___ > > James⎥Head of Trolls > > ja...@supmenow.com

Re: [swift-evolution] Shorthand unwrap proposal

On Thu, Jun 23, 2016 at 9:25 AM, James Campbell via swift-evolution wrote: > So if the function I run inside of the map has a return value of Void will > that still compile ? Yes. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j

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

On Jun 23, 2016, at 2:23 AM, Félix Cloutier via swift-evolution wrote: > Do we lose the ability to create a signed integer from an unsigned bit > pattern? The existing `init(bitPattern x: UIntN)` are still present on the concrete types in the prototype. There’s a

Re: [swift-evolution] Shorthand unwrap proposal

So if the function I run inside of the map has a return value of Void will that still compile ? *___* *James⎥Head of Trolls* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* *

Re: [swift-evolution] Shorthand unwrap proposal

I think we’d still just recommend using ‘map’ for this. The reason Collection.map and Collection.forEach are different is because we don’t promise eager and in-order evaluation for Collection.map. But Optional only executes the closure one or zero times, so there’s no ambiguity. Jordan > On

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] [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] 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] 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] [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] [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] 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

[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)

[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

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.

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

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: >

[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] [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] [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] [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

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] [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-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] [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] 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] 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] [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] [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] 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] [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] [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

  1   2   >