[swift-evolution] [Pitch] Remove type inference for associated types

[Austin Zheng via swift-evolution]

Hello all,

Per Chris Lattner's list of open Swift 3 design topics 
(http://article.gmane.org/gmane.comp.lang.swift.evolution/21369 
), I've put 
together a proposal for removing type inference for associated types.

It can be found here: 
https://github.com/austinzheng/swift-evolution/blob/az-assoctypeinf/proposals/-remove-assoctype-inference.md
 


Thoughts, criticism, and feedback welcome. There are at least two slightly 
different designs in the proposal, and I'm sure people will have ideas for even 
more.

Best,
Austin___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Jun 24, 2016, at 08:27, Vladimir.S via swift-evolution 
>  wrote:
> 
> (Personally I really don't understand why we need anything than ASCII codes 
> for identifiers. This could solve all the problems with invisible 
> space/left-to-right-flags/complicated rules/graphemes etc. But someone needs 
> to be able to put dog emoji as identifiers.. well.. OK)

Math symbols make everything better (at least if you're into math).

- Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Jun 24, 2016, at 23:13, Charlie Monroe via swift-evolution 
>  wrote:
> 
> BTW how far along with programming do you think you'd get without the 
> knowledge of English? All libraries, SDKs use English identifiers. The 
> documentation is in English. For one to lear programming without actually 
> knowing any English would require the language to have localizable 
> identifiers. Can you imagine those? Given how much time is put here to 
> standardize the naming of a few methods in the standard library, how would it 
> look in other languages?

Speaking of which, hypothetically, if we wanted to support translations of 
Swift itself (and the standard library), would it be better to have the 
compiler figure out how to make object files work across languages, or would it 
be better for the on-disk file to always be in the "canonical" language and 
have the IDE do the translation?

I'm *not* proposing we do this... Just thinking about what would need to be 
done and how hard it would be.

- Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

> On Jun 24, 2016, at 8:27 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> (Personally I really don't understand why we need anything than ASCII codes 
> for identifiers. This could solve all the problems with invisible 
> space/left-to-right-flags/complicated rules/graphemes etc. But someone needs 
> to be able to put dog emoji as identifiers.. well.. OK)

Did you even watch the WWDC keynote? This was basically the transcript of it:

"Emoji! Emoji emoji emoji. Emoji emoji. Emoji! Emoji emoji emoji emoji. Emoji 
Emoji? Emoji. Emoji!”

(cue a bunch of emoji bouncing around on an iPad screen)

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> On Jun 24, 2016, at 11:14 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> [...] what I'm trying to point out here--not mentioned previously--is that 
> one purported major benefit of `where` (putting everything on one line) is 
> inapplicable to the Swift stdlib's own style as well as those of others.

That's like saying that you can't use long method names imported from ObjC in 
Swift. Why can't you use

for anchor
in wall.anchors
where boundsRect.contains(anchor.origin) 

or similar, if you need to fit within the 80 chars - just like you'd do with a 
compound if statement that exceeds 80 chars.

The major benefit isn't saving a line (though it's 3 unless you're willing to 
add { continue } on the same line), but to express your intend to filter the 
array right within the for-in statement.

When you look around someone else's code, you immediately see that the person 
is only going through anchors without bounds without the need to examine the 
loop's body, which may be collapsed (hidden) by the editor.


> I think you made your point clearly in the discussions and proposal. Please 
> allow other people to have their own opinions in this review :), otherwise it 
> is not a review imo. 
> 
> You may note that I've confined my comments to particulars raised by others' 
> comments. And, FWIW, I haven't actually reviewed the proposal, so I'm not 
> sure how you know how I feel about it.
> 
> 
>> But 80-character lines is a common style, and I would say that a corollary 
>> of "to each their own" is that Swift's grammar should be usable and useful 
>> whether or not you adhere to such style choices.
>> 
>> If the chief advantage of `where` is that it (quoting someone above) allows 
>> one to "understand as much as possible about the control flow of the loop 
>> from a single line of code," then we ought perhaps to question its 
>> appropriateness when the majority of its benefits [by which I mean, based on 
>> your examples and Sean's, more than half of the instances in which it is 
>> used] cannot be realized in a very common coding style.
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> On Jun 24, 2016, at 9:33 PM, Xiaodi Wu  wrote:
> 
> On Fri, Jun 24, 2016 at 2:26 PM, Charlie Monroe  > wrote:
> 
>> On Jun 24, 2016, at 9:00 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> On Fri, Jun 24, 2016 at 1:56 PM, Sean Heber > > wrote:
>> > On Jun 24, 2016, at 1:30 PM, Xiaodi Wu via swift-evolution 
>> > > 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 limits, I take it?
>> >
>> > I don’t understand why anyone wouldn’t just let Xcode do the wrapping for 
>> > most cases. I’ll add newlines if I think it adds to clarity, but in 
>> > general I don’t want to code like i’m still on a Wyse WY-50.
>> >
>> > Of course, to each their own style--I certainly wouldn't want Swift to 
>> > force everyone to write lines of certain lengths. But 80-character lines 
>> > is a common style, and I would say that a corollary of "to each their own" 
>> > is that Swift's grammar should be usable and useful whether or not you 
>> > adhere to such style choices.
>> 
>> I honestly don’t believe that this a common style in the Cocoa community.
>> 
>> We're talking about the Swift community here, and Swift stdlib would be a 
>> good starting point as to what is a common or at least accepted style; it 
>> uses 80-character lines.
> 
> While it does, it makes sense only for readability purposes of the 
> documentation. For example, I see absolute no reason why to split 
> https://github.com/apple/swift/blob/master/stdlib/public/core/StringBuffer.swift#L233
>  
> 
>  into two lines.
> 
> It makes the code less readable.
> 
> 80-char style made sense in C, where everything is pretty much top-level. But 
> given that you declare a class, within which you declare another class, 
> within which you declare methods, the first level of the method indentation 
> is at level 3, which given 4 spaces per tab gives you 12 characters already. 
> Adding a few levels (for-cycle + an if statement within the for cycle) gives 
> you 20 characters of just whitespace (1/4 of the allocated 80 chars per line).
> 
> Which is why I don't believe this code style is valid in a modern language.
> 
> This is one style that some very intelligent people use in Swift. I'm not 
> going to debate what styles are "valid."

I'm sorry, if this sounded offensive in any way, I certainly did not mean it 
that way, I simply wanted to point out why I believe the 80-char limit is a bit 
limiting nowadays given that you can nest various constructs.

> My personal guess is that it should be upped to e.g. 160 chars per line - 
> that kind of makes sense. There is no particular reason other than historic 
> why we're still using 80 chars per line.
> 
>>  
>> I’m not a member of the “old guard” having only come into this world 10 
>> years ago with the iPhone, but just take a look at this delegate method in 
>> Objective-C:
>> 
>> - (void)locationManager:(CLLocationManager *)manager 
>> rangingBeaconsDidFailForRegion:(CLBeaconRegion *)region withError:(NSError 
>> *)error;
>> 
>> That’s well over 80 characters all by itself. This fits on my screen in a 
>> single line - and I work on a 15” MBP with room for my dock always visible 
>> on the side along with Xcode’s sidebar open! On a typical desktop-sized 
>> screen, 80-col lines must be comically short.
>> 
>> I don’t know why it should be assumed that people are adhering to a 
>> so-called standard that dates back to terminal screens that didn’t have 
>> color.
>> 
>> 
>> > If the chief advantage of `where` is that it (quoting someone above) 
>> > allows one to "understand as much as possible about the control flow of 
>> > the loop from a single line of code," then we ought perhaps to question 
>> > its appropriateness when the majority of its benefits [by which I mean, 
>> > based on your examples and Sean's, more than half of the instances in 
>> > which it is used] cannot be realized in a very common coding style.
>> 
>> Again, I dispute the idea (having no data but my own :P) that 80-col limits 
>> are common in this community.
>> 
>> l8r
>> Sean
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
___
swift-evolution mailing list
swift-evolution@swift.org

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

[Charlie Monroe via swift-evolution]

> On Jun 25, 2016, at 12:21 AM, Magnus Ahltorp  wrote:
> 
>> 21 June 2016 16:48 Vladimir.S via swift-evolution wrote:
>> 
>> On 21.06.2016 7:37, Charlie Monroe via swift-evolution wrote:
>>> 
 On Jun 21, 2016, at 2:23 AM, Brent Royal-Gordon via swift-evolution
  wrote:
 
> Perhaps stupid but: why was Swift designed to accept most Unicode
> characters in identifier names? Wouldn’t it be simpler to go back to
> a model where only standard ascii characters are accepted in
> identifier names?
 
 I assume it has something to do with the fact that 94.6% of the
 world's population speak a first language which is not English. That
 outweighs the inconvenience for Anglo developers, IMHO.
>>> 
>>> Yes, but the SDKs (frameworks, system libraries) are all in English,
>>> including Swift standard library. I remember a few languages attempting
>>> localized versions for kids to study better, failing terribly because
>>> you learned something that had a very very limited use.
>> 
>> Support Charlie's opinion. For me (as non-native English speaker) non-ASCII 
>> characters in identifiers had no sense, even when I start to tech the 
>> programming when I was a child. Expressions composed from identifiers 
>> written in my native language is not near correct sentences.
>> 
>> Even more, we still have all other parts of language in English - 
>> for-while-guard-let-var-func etc..
> 
> As far as I can see, forcing the programmer to write identifiers in an 
> only-ASCII language, and requiring that identifier names have to be 
> meaningful to the programmer means that the programmer has to know a language 
> that is written in only ASCII. Most people are not, and requiring that they 
> first learn for example English to be able to write programs is absurd.

You can always write your identifier using ASCII. For languages that use the 
latin script, just extended with various accents, can be written without them 
(this is how I was taught). Any language I'm aware of can be eventually written 
in the latin script (Chinese, cyrilic, ...). 

BTW how far along with programming do you think you'd get without the knowledge 
of English? All libraries, SDKs use English identifiers. The documentation is 
in English. For one to lear programming without actually knowing any English 
would require the language to have localizable identifiers. Can you imagine 
those? Given how much time is put here to standardize the naming of a few 
methods in the standard library, how would it look in other languages? 

> 
> Of course, if we relax the rule that identifier names have to be meaningful 
> to the programmer, then it works out, but that is not something that I feel 
> the Swift community should encourage.
> 
> The few symbols that are in English can be learned as what they are, symbols, 
> without knowing their English meaning, just like &, |, <, >, *, and so on are 
> symbols. In fact, you all learn these words as symbols that are distinct from 
> their English connotations, since Swift is definitely not English text.
> 
> /Magnus
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> As detailed in the proposal, the keywords cover the space of continue false, 
> continue true,  break true, break false.

But the goal of covering all four of these options is arbitrary and 
inconsistent with the rest of the language. Moreover, it's arbitrary and 
inconsistent in a way that inflates the apparent magnitude of the problem.

Firstly: There is no need whatsoever for both "true" and "false" versions of 
each condition. Swift doesn't have `if` and `unless`, or `guard` and `prevent`, 
or `while` and `until`. It expects you to use the not operator or reverse the 
sense of your comparisons (`!=` instead of `==`, `>=` instead of `<`, etc.). We 
can do the same thing here. If `if !` is good enough, then so is `where !`.

Secondly: Yes, `where` and `while` are both available as list operations 
(`filter` and `prefix(while:)`), but so are `map` and `sorted`, and nobody is 
suggesting we need those as keywords. (Well, some people have suggested some 
additional `for` keywords, but they're wrong.) If we feel that `where` is 
special, there's nothing wrong with offering only `where`.

And I *would* argue that `where` is special. It's special because skipping an 
element feels less like control flow than terminating a loop. It's special 
because `where` is not order-dependent, but `while` is. It's special because 
terminating the loop is a more drastic action. It's special because the 
`continue` keyword is less clear than the `break` keyword, but is considered an 
inviolable term of art. It's special because I suspect (but admittedly cannot 
prove) that `continue` is more frequently used at the top of a loop, controlled 
by a single conditional statement based on a side-effect-free boolean 
operation, than `break`.

Think of it this way: We have not accepted the often-proposed `else`-less 
`guard`, but if we did, there is broad agreement that, absent an "always 
`return`" rule for simplicity, the most obvious body to infer inside a loop is 
`continue`. There are reasons for that, and they're the exact same reasons we 
support `where` but not `while`.

* * *

My review of this proposal follows.

>   * What is your evaluation of the proposal?

I think the motivation is weak and do not find it compelling.

The "elevates one style above other related styles" motivation fails to 
convince me for the reasons described above; "difficult to document separately 
at its point of use" can be addressed simply by adding a newline before the 
`where` clause; "hard to breakpoint and debug" is true of any expression, and 
is easily addressed by extracting that expression into an inner function; and 
"rarely used" is, in my opinion, more a result of how it is taught and 
documented than of how useful it is.

In my opinion, the *only* valid argument cited for the removal of `where` is 
that learners sometimes misunderstand it. I'm very sympathetic to learners, and 
I would like to improve their experience with this feature. But there are many 
other ways to help them, like:

* Making sure that "The Swift Programming Language" teaches the use of 
`for`/`where`.

* Adding help content for language keywords to Xcode and Swift Playgrounds.

* Making syntax adjustments that might improve clarity, like my suggestion that 
putting the `where` clause next to the variable might clarify that you are 
filtering the values which will be seen inside the loop.

* Changing the keyword, if a better keyword can be found.

But at this point, measures like these have not been tried, and I have not 
heard convincing arguments that they will not work.

Meanwhile, the proposal does not address the problems it causes, suggest that 
they *should* be addressed in a future proposal, or even acknowledge that there 
*are* any problems. If `where` is removed, none of its alternatives are nearly 
as good:

* `guard`/`else`/`continue` clutters the logic with completely avoidable 
boilerplate.

More worryingly, it obscures the intent: "Skip elements like this" becomes 
"Elements must be like this, and if they're not, go to the next element". 
Converting a meaning into mechanical instructions to achieve it is not an 
improvement. If we wanted to do that, we could dispose of `for`/`in` entirely 
and replace it with:

var iterator = collection.makeIterator()
while let elem = iterator.next() { … }

Folks who wrote AppKit code on Tiger would feel right at home.

* `filter(suchThat:)` (or whatever we call it) is dramatically less efficient 
and has syntactic issues with that particular slot because trailing closures 
are unavailable.

* `lazy.filter(suchThat:)` lies on a narrow golden path (it's all too easy to 
forget the `lazy`) and still has the same syntactic issues as a plain `filter`.

We retired `where` clauses from `if` statements because they were a grammatical 
hack, an unnatural usage forced on us by the desire to support a feature 
(multiple optional bindings or pattern matches per keyword) that, in hindsight, 
we realized 

Re: [swift-evolution] Shorthand unwrap proposal

[Rob Mayoff via swift-evolution]

This is equivalent to the “Add an ifPresent function to Optional”
suggestion made back in March.

http://thread.gmane.org/gmane.comp.lang.swift.evolution/9173

Personally I'd prefer an `ifPresent` or `foreach` method to using
`map`, as `ifPresent` or `foreach` would make it clearer to the reader
that no return value is expected or wanted from either `ifPresent` or
the block it calls.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joe Groff via swift-evolution]

> On Jun 23, 2016, at 8:55 PM, 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, although when I set out 
> earlier today to record my usual rebuttal I found that it really was mostly a 
> matter of taste. Yes, this looks weird to me:
> 
> let callback: (Data) -> NSCoding & NSCopying
> 
> but I’m sure the infix ‘->’ for functions looked weird to everyone the first 
> time they saw it as well, and it really is pretty clear in argument position.

We could conceivably bracket the 'where' constraints somewhere. It's nice not 
to have to punish the common case syntax. In my personal ideal vision of the 
world, I'd like to see us support opening existentials via path-dependent types 
(e.g., let a: Collection; let element: a.Element). If we support them in 
decl-level 'where' clauses, we provide a nice, clean syntax for complex generic 
relationships that doesn't require angle brackets or per-existential where 
clauses at all, something like:

func intersect(a: Collection, b: Collection) -> Collection
where a.Element == b.Element, b.Element == return.Element {
}

which doesn't completely define away the need for 'where' as part of 
existential types, but would shrink it quite a bit.

-Joe

> However, I did remember one issue, which was brought up on the previous 
> mega-thread: if we do want to generalize protocol values, we’re going to want 
> something that’s essentially “a type with a ‘where’ clauses in it”. I really 
> don’t want to force people to use a typealias to spell such a type, but at 
> the same time I want that where clause to be clearly attached to the type. 
> (As brought up before the return position of a function is currently 
> ambiguous with SE-0081.)
> 
> Despite the lightweightedness and the well-prepared proposal by Adrian and 
> Austin, the lack of bracketing <> () {} [] leads me to maintain my stance 
> against the proposed syntax.
> 
> Jordan
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

> On Jun 24, 2016, at 15:03, Nicola Salmoria via swift-evolution 
>  wrote:
> 
> 
> 
> On Fri, Jun 24, 2016 at 11:45 PM, Max Moiseev  > wrote:
>> However, division by 0 isn't an overflow: it's an undefined operation. I 
>> find it somewhat surprising that dividedWithOverflow/remainderWithOverflow 
>> allow attempting this operation.
> I tried to say that in my previous email. I agree that division by zero is 
> NOT the overflow and should probably be handled differently if only for a 
> better error message.
> 
>> 
>> To me, the intuitive semantics of the WithOverflow methods are "perform the 
>> operation, and if the result doesn't fit in the given type, return a 
>> truncated result and an overflow flag". This is not what happens when 
>> dividing by 0, because the result simply doesn't exist.
>> 
>> I think I would prefer if rhs != 0 was documented as an explicit 
>> precondition of the division and remainder operations, and 
>> dividedWithOverflow/remainderWithOverflow trapped because of precondition 
>> failure.
> That’s exactly how it is implemented in the prototype now.
> 
> Now I'm confused. Isn't this line of the gyb returning .overflow when the 
> divisor is 0?
> https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L793
>  
> 
> 
> Also, the current version of Swift doesn't trap either:
> let z = 0
> print(Int.divideWithOverflow(1, z))// (0, true)
> print(Int.remainderWithOverflow(1, z))// (0, true)
> 
> interestingly, you need to put 0 in a variable otherwise the compiler rejects 
> the lines.

Huh. My bad for not checking. Yeah, I don't think dividing by zero and dividing 
INT_MIN by -1 are the same kind of overflow.

Jordan___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[William Jon Shipley via swift-evolution]

> On Jun 24, 2016, at 3:00 PM, Haravikk via swift-evolution 
>  wrote:
>for colinearSegment in remainingSegments where 
> colinearSegment.angle.isEssentially(angle: segment.angle) { // Is parameter 
> name even necessary?

My terminology sucks because I don’t remember math terms but basically I’m 
trying to distinguish between angles of rays (0..<360º) and angles of lines 
(0..<180º). Because, like, if you have a line at 45º and another at 225º, well, 
they’re either collinear or parallel.

So I call the variants “rayAngle:” and “infiniteLineAngle:”. Not my finest hour.

-W___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

As someone who’ll likely make use of this protocol, I’m in favor of a 
“halfWidthDivide” (or whatever it’s called). As someone who’ll likely end up 
writing at least one type which will conform to `Integer`, I’m not looking 
forward to implementing 503 little functions & computed properties (although 
I’ll admit it’ll be worth it to get a nice integer protocol). Is there any 
chance the protocol be able to provide default implementations for any of the 
“metadata” kind of stuff?

Also, speaking of default implementations, “wouldn’t it be nice if...” we only 
had to define everything explicitly for `IntN`, `UIntN` and `DoubleWidth`, 
and the compiler was smart enough to figure out that, say, `DoubleWidth` 
was semantically identical to `Int16` and would automatically promote it to the 
native type whenever possible… That way we wouldn’t need the .gyb files to 
write the code for all the integer types, *and* we wouldn’t have to pay the 
speed penalty for having, say, "func *(Int, Int)->Int" be the same code path as 
"func *(DoubleWidth>, 
DoubleWidth>) -> 
DoubleWidth>”, *and* we’d get arbitrary-width 
ints for free (well, “arbitrary” in terms of powers of 2).

- Dave Sweeris

> On Jun 24, 2016, at 2:01 PM, Károly Lőrentey via swift-evolution 
>  wrote:
> 
> The operation I want is the inverse of doubleWidthMultiply, where you have a 
> (high, low) word pair and you want to divide it by a single word, getting a 
> quotient and remainder. This is an important building block for implementing 
> arbitrary precision division. Intel’s DIV can do this in a single 
> instruction, while doing it in code requires a lot of work:
> 
> https://github.com/lorentey/BigInt/blob/swift3/Sources/BigDigit.swift#L119-L176
> 
>> On 2016-06-24, at 20:52, Haravikk  wrote:
>> 
>> 
>>> On 24 Jun 2016, at 18:17, Károly Lőrentey via swift-evolution 
>>>  wrote:
>>> I’m especially stoked about `FixedWidthInteger.doubleWidthMultiply`, which 
>>> will likely lead to a measurable speedup. Why is there no 
>>> `doubleWidthQuotientAndRemainder` or `doubleWidthDivide`, though?
>> 
>> Double-width isn't needed for these as it's impossible for an integer to 
>> become larger when dividing (the smallest value you can divide by and get a 
>> result is 2, which will halve the value), and the remainder can't be larger 
>> than the original value.
>> 
>> 
>> Anyway, I'm hugely in favour of this proposal, it's desperately needed!
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Alejandro Martinez via swift-evolution]

+1
I've read the proposal and I've been following the conversation for some days 
now.
I don't have anything else to add to the concerns that have already been 
discussed, but I would like to reiterate on the fact that having the 
,absoluteValue, property but without substituting 'abs' will induce a lot of 
programers to use it anyway and make mistakes.
That's my only concern with it, the rest looks awesome. It is really amazing to 
see the power of protocols.
Thanks for the proposal 


Sent from my iPad

> On 23 Jun 2016, at 01:52, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0104: Protocol-oriented integers" begins now and runs 
> through June 27. The proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>* What is your evaluation of the proposal?
>* Is the problem being addressed significant enough to warrant a change to 
> Swift?
>* Does this proposal fit well with the feel and direction of Swift?
>* If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 24 Jun 2016, at 22:33, Erica Sadun via swift-evolution 
>  wrote:
> 
> most of these read as if there is too much logic stuffed into a single line:
> 
>> for otherWall: Wall in self where otherWall != wall && 
>> !removedWalls.contains(otherWall) {
>> 
>> for otherPieceOfFurnitureNode in 
>> localFurnitureModelUUIDsToInterfaceElements!.values where 
>> otherPieceOfFurnitureNode !== pieceOfFurnitureNode {
>> 
>> for lineSegmentObject in wallRelatedLineSegments where 
>> remainingLineSegments.contains(lineSegmentObject) {
>> 
>> for colinearLineSegmentObject in remainingLineSegments where 
>> colinearLineSegmentObject.angle.isEssentially(infiniteLineAngle: 
>> lineSegmentObject.angle) {
>> …

Personally the logic seems pretty simple to me (especially the second and third 
one, plus the fourth isn't actually complex), I'd say the biggest problem to 
readability here is that the names seem too verbose, though without seeing the 
rest of the code that's hard to judge. For example the last example doesn't 
look so bad if you shorten the names like so:

 for colinearSegment in remainingSegments where 
colinearSegment.angle.isEssentially(angle: segment.angle) { // Is parameter 
name even necessary?

Basically on the basis that it's probably obvious from context that this is to 
do with lines that this is to do with lines, not sure if .isEssentially()'s 
parameter name can be changed, but I'm not sure why there needs to be a 
distinction that the angle is for an infinite line (an angle is an angle).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Fri, Jun 24, 2016 at 4:33 PM, Erica Sadun  wrote:

>
> On Jun 24, 2016, at 12:04 AM, Xiaodi Wu  wrote:
>
> On Fri, Jun 24, 2016 at 12:59 AM, William Shipley via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Here are some of my real-world examples:
>>
>> for modelUUIDAndInterfaceElement in modelUUIDsToInterfaceElements
>> where !usedInterfaceElements.contains(modelUUIDAndInterfaceElement.1) {
>>
>
> Not a practitioner of 80-character line limits, I take it?
>
>
> 80-character line limits aren't why these examples  are problematic for me.
>

Sorry, I'm going to selfishly interject here to clarify what I meant by
that question to Wil.

I was not implying that his code was problematic for me--far be it from me
to critique Wil's code or style, a task for which I'm not qualified. And
I'm truly appreciative that Wil was willing to share his code so that we
could learn about the use of `where` in closed-source contexts.

The point I was trying to bring up was that a purported advantage of
keeping `where` is moot for those who *do* observe line limits, which
includes the Swift stdlib itself as well as (IIUC) house style at Google,
Microsoft, etc.


> Other than a few positive examples like this wall.anchors one,
>
>  for anchor in wall.anchors where boundsRect.contains(anchor.
> origin) {
>
>
> most of these read as if there is too much logic stuffed into a single
> line:
>
> for otherWall: Wall in self where otherWall != wall && !removedWalls.
>> contains(otherWall) {
>>
>>
>> for otherPieceOfFurnitureNode in
>> localFurnitureModelUUIDsToInterfaceElements!.values where
>> otherPieceOfFurnitureNode !== pieceOfFurnitureNode {
>>
>>
>> for lineSegmentObject in wallRelatedLineSegments where
>> remainingLineSegments.contains(lineSegmentObject) {
>>
>>
>> for colinearLineSegmentObject in remainingLineSegments where
>> colinearLineSegmentObject.angle.isEssentially(infiniteLineAngle:
>> lineSegmentObject.angle) {
>>
>> …
>>
>>
> -- E
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Collection index complexity and data structures

[Haravikk via swift-evolution]

I started a discussion thread that may be of interest to you, basically 
discussing the possibility for directional methods to reduce confusion/clarify 
intent, should be accessible at the following URL:
http://thread.gmane.org/gmane.comp.lang.swift.evolution/19185/focus=19613

> On 24 Jun 2016, at 22:05, David Waite via swift-evolution 
>  wrote:
> 
> And never mind me. Not sure how I missed that in the docs that many times.
> 
> -DW
> 
>> On Jun 24, 2016, at 1:38 PM, David Waite via swift-evolution 
>> > wrote:
>> 
>> I noticed that the new Collection index(_:offsetBy:) 
>>  
>> does not define that negative offsets require a BidirectionalCollection. It 
>> also declares that negative offsets must complete in O( | offset | ) time. 
>> This differs from other methods such as distance(from:to:) 
>> which
>>  indicates start <= end if not a BidirectionalCollection
>> 
>> This would preclude some data structures from strictly implementing the 
>> Collection protocol, such as singly-linked lists.
>> 
>> Would it be appropriate to indicate instead that BidirectionalCollection 
>> defines the negative offset behavior and negative offset performance 
>> constraint?
>> 
>> -DW
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Max Moiseev via swift-evolution]

> However, division by 0 isn't an overflow: it's an undefined operation. I find 
> it somewhat surprising that dividedWithOverflow/remainderWithOverflow allow 
> attempting this operation.
I tried to say that in my previous email. I agree that division by zero is NOT 
the overflow and should probably be handled differently if only for a better 
error message.

> 
> To me, the intuitive semantics of the WithOverflow methods are "perform the 
> operation, and if the result doesn't fit in the given type, return a 
> truncated result and an overflow flag". This is not what happens when 
> dividing by 0, because the result simply doesn't exist.
> 
> I think I would prefer if rhs != 0 was documented as an explicit precondition 
> of the division and remainder operations, and 
> dividedWithOverflow/remainderWithOverflow trapped because of precondition 
> failure.
That’s exactly how it is implemented in the prototype now.

> If it is desirable that the WithOverflow methods never trap, then I think it 
> would be better to add a `divisionByZero` case to the ArithmeticOverflow enum 
> and return that instead of the generic `overflow`.
Nice idea, but I don’t think it is really required that WithOverflow methods 
should never fail. The main idea behind these methods is to allow for 2 
versions of arithmetic operations: one that traps on overflow and an unsafe 
one, that simply discards the overflow flag returning the partial result. Both 
of these however should, in my opinion, trap in a truly exceptional case of 
division by 0.

Thanks for your comments, Nicola!

Max

> On Jun 23, 2016, at 11:06 PM, Nicola Salmoria  
> wrote:
> 
> 
> 
> On Fri, Jun 24, 2016 at 12:12 AM, Max Moiseev  > wrote:
> 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 that remainder is special, let me see what I can do about it.
> 
> 
> LOL, yes of course, I forgot about the obvious trapping case.
> 
> However, division by 0 isn't an overflow: it's an undefined operation. I find 
> it somewhat surprising that dividedWithOverflow/remainderWithOverflow allow 
> attempting this operation.
> 
> To me, the intuitive semantics of the WithOverflow methods are "perform the 
> operation, and if the result doesn't fit in the given type, return a 
> truncated result and an overflow flag". This is not what happens when 
> dividing by 0, because the result simply doesn't exist.
> 
> I think I would prefer if rhs != 0 was documented as an explicit precondition 
> of the division and remainder operations, and 
> dividedWithOverflow/remainderWithOverflow trapped because of precondition 
> failure.
> 
> If it is desirable that the WithOverflow methods never trap, then I think it 
> would be better to add a `divisionByZero` case to the ArithmeticOverflow enum 
> and return that instead of the generic `overflow`.
> 
> Thanks,
> Nicola
> 
>  
> Thanks,
> Max
> 
> 
> > On Jun 23, 2016, at 2:38 PM, Nicola Salmoria via swift-evolution 
> > > wrote:
> >
> > Max Moiseev via swift-evolution  writes:
> >
> >>> For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under
> > what situations would
> >> you have an overflow? I could only come up with something like
> > Int.min.dividedWithOverflow(-1).
> >> If you look at the prototype here:
> >>
> > https://github.com/apple/swift/blob/master/test/Prototypes 
> > 
> > /Integers.swift.gyb#L789
> >> there is
> >> exactly the check that you’ve mentioned, but for all signed integers.
> > Besides, it is very convenient to
> >> have all the arithmetic operations be implemented the same way, even if
> > there were no real overflows for division.
> >
> > I agree with this for the four basic operations, but not for the remainder
> > operation.
> >
> > By definition, the remainder is always strictly smaller (in absolute value)
> > than the divisor, so even if the division itself overflows, the remainder
> > must be representable, so technically it never overflow.
> >
> > In the only actual case where the division overflow, that is Int.min / -1,
> > the remainder is simply 0.
> >
> > For these reasons, I think it would make sense to explicitly request that
> > the remainder operation never traps, and remove the overflow variants.
> >
> > Nicola
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> 
> 
> 
> On Fri, Jun 24, 2016 at 12:12 

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

[Max Moiseev via swift-evolution]

> On Jun 23, 2016, at 8:47 PM, Félix Cloutier  wrote:
> 
> 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?
It is in the prototype: 
https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L334

> 
> Félix
> 
>> Le 23 juin 2016 à 17:36:14, Max Moiseev via swift-evolution 
>> > a écrit :
>> 
>>> > For Integer, does the presence of signBit indicate an expectation that 
>>> > signed Integers will have a two's complement representation?
>>> Yes. That is correct.
>>> 
>>> So would this require a BigInt implementation to be in two's complement 
>>> also? Most BigInt implementations use a separate sign I think, not sure if 
>>> that's for performance reasons or merely convenience though.
>> 
>> 
>> This is a very valid concern. I think I have discovered a truly marvelous 
>> solution a way of addressing it:
>> 
>> `signBitIndex` is only used (I’m talking about the prototype now) to 
>> determine the absolute required minimum of bits needed to represent the 
>> current value of number when converting it to a different type.
>> 
>> So, instead of mentioning the sign bit, let’s call it what it is 
>> ‘minimumRequiredWidth’ or something along this line. This move will also 
>> allow the default implementation of `minimumRequiredWidth` to simply return 
>> `bitWidth` for unsigned numbers and and `bitWidth - 1` for positive signed, 
>> etc.
>> 
>> This way bignum implementations don’t have to have any specific underlying 
>> representation. They can either inherit the default implementation or 
>> implement their own version of `minimumRequiredWidth` in case the `bitWidth` 
>> has some extra unused space that is not absolutely required.
>> 
>> I still need to validate this idea, these are just the thoughts. Any 
>> comments are more than welcome.
>> 
>> Max
>> 
>> 
>>> On Jun 23, 2016, at 3:19 PM, Patrick Pijnappel >> > wrote:
>>> 
>>> - I remain unconvinced that defining an Arithmetic that includes both exact 
>>> and floating-point numbers is a good idea. All of the arguments from Swift 
>>> 1 and 2 about why we didn't include this still seem relevant. To phrase it 
>>> in generic programming terms, what algorithm would be generic over 
>>> Arithmetic?
>>> 
>>> E.g. generic point/size/rect types.
>>> 
>>> > For Integer, does the presence of signBit indicate an expectation that 
>>> > signed Integers will have a two's complement representation?
>>> Yes. That is correct.
>>> 
>>> So would this require a BigInt implementation to be in two's complement 
>>> also? Most BigInt implementations use a separate sign I think, not sure if 
>>> that's for performance reasons or merely convenience though.
>>> 
>>> 
>>> On Fri, Jun 24, 2016 at 7:40 AM, Jordan Rose via swift-evolution 
>>> > wrote:
>>> Oh, one more comment: I suggest naming the primary protocol something other 
>>> than "Integer", which IMHO is a little close to "Int" for a beginner. 
>>> "Integral" is a bit too ambiguous, but maybe "IntegerArithmetic" or 
>>> "ArithmeticInteger"? Or to go with the representation thing, 
>>> "BinaryInteger"? (Some of the requirements are at odds with a decimal-based 
>>> implementation.)
>>> 
>>> Jordan
>>> 
>>> 
 On Jun 23, 2016, at 13:50, Jordan Rose > wrote:
 
 Hey, standard library folks. Glad we're doing this one. :-)
 
 - I remain unconvinced that defining an Arithmetic that includes both 
 exact and floating-point numbers is a good idea. All of the arguments from 
 Swift 1 and 2 about why we didn't include this still seem relevant. To 
 phrase it in generic programming terms, what algorithm would be generic 
 over Arithmetic?
 
 
 - What is Integer.init(_:) supposed to do if the 
 floating-point value is larger than the maximum representable integer? 
 Smaller than the minimum? (As a special case, negative, when the integer 
 type is unsigned?) Infinity? NaN?
 
 - Integer.init(_:) currently says "if it is representable". It 
 should say something like "trapping if it is not representable".
 
 - I find it odd that Integer.init(clamping:) privileges the bounds of 
 fixed-width integers. I was going to suggest it should take a range to 
 clamp to that defaults to the min and max, but that's not implementable 
 for a BigInt.
 
 - nthWord should count "from least-significant to most-significant" rather 
 than "from the right".
 
 - As mentioned before, it sounds like Integer requires a two's complement 
 representation (if only so the result of nthWord can be interpreted 

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

[Erica Sadun via swift-evolution]

> On Jun 24, 2016, at 12:04 AM, Xiaodi Wu  wrote:
> 
> On Fri, Jun 24, 2016 at 12:59 AM, William Shipley via swift-evolution 
> > wrote:
> Here are some of my real-world examples:
> 
> for modelUUIDAndInterfaceElement in modelUUIDsToInterfaceElements 
> where !usedInterfaceElements.contains(modelUUIDAndInterfaceElement.1) {
> 
> Not a practitioner of 80-character line limits, I take it?

80-character line limits aren't why these examples  are problematic for me.
Other than a few positive examples like this wall.anchors one, 

>  for anchor in wall.anchors where boundsRect.contains(anchor.origin) {

most of these read as if there is too much logic stuffed into a single line:

> for otherWall: Wall in self where otherWall != wall && 
> !removedWalls.contains(otherWall) {
> 
> for otherPieceOfFurnitureNode in 
> localFurnitureModelUUIDsToInterfaceElements!.values where 
> otherPieceOfFurnitureNode !== pieceOfFurnitureNode {
> 
> for lineSegmentObject in wallRelatedLineSegments where 
> remainingLineSegments.contains(lineSegmentObject) {
> 
> for colinearLineSegmentObject in remainingLineSegments where 
> colinearLineSegmentObject.angle.isEssentially(infiniteLineAngle: 
> lineSegmentObject.angle) {
> …

-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] UnsafeRawPointer API

[Alejandro Martinez via swift-evolution]

Awesome changes! Thanks for working on this.
The final section address all the concerns that I was having while
reading which is really interesting for a proposal of this kind.
I’m glad to see improvements on this part of the API.
I pointed out a minor typo on twitter, sorry didn’t saw this thread
before ;) https://twitter.com/alexito4/status/746420742661771265

Can’t wait to see be able to use this ;)
Cheers,


On Fri, Jun 24, 2016 at 8:38 PM, Matthew Johnson via swift-evolution
 wrote:
>
>
> Sent from my iPad
>
> On Jun 24, 2016, at 1:27 PM, John McCall  wrote:
>
> On Jun 24, 2016, at 10:58 AM, Andrew Trick via swift-evolution
>  wrote:
>
> On Jun 24, 2016, at 8:19 AM, Matthew Johnson  wrote:
>
> Andrew, thank you for working on this.  The latest draft is much improved!
>
> I have a few questions.
>
> Why do you require explicitly passing the type in these signatures?
>
> func initialize(_: T.Type, with: T, count: Int = 1) ->
> UnsafeMutablePointer
> func initialize(toContiguous: T.Type, atIndex: Int, with: T) ->
> UnsafeMutablePointer
> func storeRaw(_: T.Type, with: T)
> func storeRaw(toContiguous: T.Type, atIndex: Int, with: T)
>
> There is probably a good reason, but it seems redundant at first glance and
> isn’t obvious from my reading of the proposal.  The alternatives would be
> something like this:
>
> func initialize(with: T, count: Int = 1) -> UnsafeMutablePointer
>
>
> Good question. It is deliberately, and unfortunately redundant. We're
> trading convenience for safety. I added this note to the proposal:
>
> Note that the `T.Type` argument on `initialize` is redundant because
> it may be inferred from the `with` argument. However, relying on type
> inferrence at this point is dangerous. The user needs to ensure that
> the raw pointer has the necessary size and alignment for the
> initialized type. Explicitly spelling the type at initialization
> prevents bugs in which the user has incorrectly guessed the inferred
> type.
>
>
> One major problematic case: the value could have a defaulted type, e.g.:
>   pointer.initialize(with: 0, count: 1024)
>
>
> Yes, this one crossed my mind.  :)
>
> It would be more convenient to not have to explicitly pass the type in every
> case even if we had to explicitly specify it here like
> 'pointer.initialize(with: Int(0), count: 1024)' but there probably isn't a
> good way to require it only in cases like this.   And given the safety
> concerns I think the minor inconvenience is very warranted.  In any case,
> it's nice to have the rationale documented in the proposal.
>
>
> John.
>
>
> The parameter order in this signature is the opposite of the order in
> UnsafeMutablePointer.  Is that intentional?  If so, what is the rationale?
> You might want to elaborate this in the proposal.
>
> public func + (lhs: Int, rhs: UnsafeRawPointer) -> UnsafeRawPointer
>
>
> Fixed.
>
> Shouldn’t the precondition be that memory for all elements is
> *uninitialized* / *deinitialized* in this example?
>
> // - precondition: memory for all elements is initialized.
> func freeCBuffer() {
>   UnsafeRawPointer(ptrToA).deallocate(capacity: eltCount, of: A.self)
> }
>
>
>
> Typo. Thanks!
>
> It looks like there is a type in this example:
>
> var anyT = T(...)
> takesTPtr()
> takesVoidPtr()
>
>
> Should the last line say ``?
>
>
> Typo. Thanks!
>
> -Andy
>
> Other than these few questions all I can say is that this looks great!  I
> believe it will add important clarity to code that works with unsafe
> pointers.
>
> -Matthew
>
> On Jun 23, 2016, at 8:40 PM, Andrew Trick via swift-evolution
>  wrote:
>
> 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, and the
> memory model has been simplified and clarified.
>
> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md
>
> If you have opinions or suggestions on API syntax, please make yourself
> heard. You can jump straight to the naming discussion here:
>
> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md#variations-under-consideration
>
> Of particular interest may be the API names for:
>
> - Memory allocation/deallocation: fairly fundamental to the language.
>
> - Unsafe casting from raw pointers to typed pointers. This is going to
> impact a lot of code that needs C interoperability.
>
> Keep in mind that we will make additive API improvements later for
> convenience. We want the fundamentals to be clear, explicit, and reasonably
> safe.
>
> -Andy
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

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

[Xiaodi Wu via swift-evolution]

On Fri, Jun 24, 2016 at 4:04 PM, Jose Cheyo Jimenez 
wrote:

>
>
> On 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 limits, I take it?
>>
>>
>> I don’t understand why anyone wouldn’t just let Xcode do the wrapping for
>> most cases. I’ll add newlines if I think it adds to clarity, but in general
>> I don’t want to code like i’m still on a Wyse WY-50.
>>
>
> Of course, to each their own style--I certainly wouldn't want Swift to
> force everyone to write lines of certain lengths.
>
>
> The fact that you bring up a style in a proposal review [about a style
> imo] (and thus distracting the review process ) just reinforces the
> thinking that the proposal is about enforcing a particular style.
>

On the contrary, new data have been presented on how `where` is being used.
These raise a point that `where` promotes a particular style over others,
and what I'm trying to point out here--not mentioned previously--is that
one purported major benefit of `where` (putting everything on one line) is
inapplicable to the Swift stdlib's own style as well as those of others. It
is not a distraction to tackle new points that are brought up during the
review process.


> I think you made your point clearly in the discussions and proposal.
> Please allow other people to have their own opinions in this review :),
> otherwise it is not a review imo.
>

You may note that I've confined my comments to particulars raised by
others' comments. And, FWIW, I haven't actually reviewed the proposal, so
I'm not sure how you know how I feel about it.


> But 80-character lines is a common style, and I would say that a corollary
> of "to each their own" is that Swift's grammar should be usable and useful
> whether or not you adhere to such style choices.
>
> If the chief advantage of `where` is that it (quoting someone above)
> allows one to "understand as much as possible about the control flow of
> the loop from a single line of code," then we ought perhaps to question its
> appropriateness when the majority of its benefits [by which I mean, based
> on your examples and Sean's, more than half of the instances in which it is
> used] cannot be realized in a very common coding style.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> On Jun 24, 2016, at 11:30 AM, Xiaodi Wu via swift-evolution 
>  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 limits, I take it?
>> 
>> I don’t understand why anyone wouldn’t just let Xcode do the wrapping for 
>> most cases. I’ll add newlines if I think it adds to clarity, but in general 
>> I don’t want to code like i’m still on a Wyse WY-50.
> 
> Of course, to each their own style--I certainly wouldn't want Swift to force 
> everyone to write lines of certain lengths.

The fact that you bring up a style in a proposal review [about a style imo] 
(and thus distracting the review process ) just reinforces the thinking that 
the proposal is about enforcing a particular style. 

I think you made your point clearly in the discussions and proposal. Please 
allow other people to have their own opinions in this review :), otherwise it 
is not a review imo. 

> But 80-character lines is a common style, and I would say that a corollary of 
> "to each their own" is that Swift's grammar should be usable and useful 
> whether or not you adhere to such style choices.
> 
> If the chief advantage of `where` is that it (quoting someone above) allows 
> one to "understand as much as possible about the control flow of the loop 
> from a single line of code," then we ought perhaps to question its 
> appropriateness when the majority of its benefits [by which I mean, based on 
> your examples and Sean's, more than half of the instances in which it is 
> used] cannot be realized in a very common coding style.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Collection index complexity and data structures

[David Waite via swift-evolution]

And never mind me. Not sure how I missed that in the docs that many times.

-DW

> On Jun 24, 2016, at 1:38 PM, David Waite via swift-evolution 
>  wrote:
> 
> I noticed that the new Collection index(_:offsetBy:) 
>  
> does not define that negative offsets require a BidirectionalCollection. It 
> also declares that negative offsets must complete in O( | offset | ) time. 
> This differs from other methods such as distance(from:to:) 
> which
>  indicates start <= end if not a BidirectionalCollection
> 
> This would preclude some data structures from strictly implementing the 
> Collection protocol, such as singly-linked lists.
> 
> Would it be appropriate to indicate instead that BidirectionalCollection 
> defines the negative offset behavior and negative offset performance 
> constraint?
> 
> -DW
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Jun 24, 2016, at 3:06 PM, Xiaodi Wu  wrote:
> 
> 
> 
> On Fri, Jun 24, 2016 at 2:50 PM, Matthew Johnson via swift-evolution 
> > wrote:
> 
>> On Jun 24, 2016, at 10:41 AM, Adrian Zubarev via swift-evolution 
>> > wrote:
>> 
>> That said, how about this design:
>> 
>> public protocol _LiteralNilProtocol { … }
>> …
>> 
>> public enum Literal {
>>  
>> public typealias NilProtocol = …
>> …
>> }
> I’m pretty sure the standard library team intends to reserve the right to use 
> this namespace for other protocols that only exist for syntactic support.  
> This may not always be literals - there may be other kinds of syntax 
> supporting protocols in the future.  With that in mind I don’t think this 
> design will work.
> 
> That said, `IntegerLiteralProtocol` or `Syntax.IntegerLiteralProtocol` both 
> read very nicely, IMO, so that aspect of the idea is worth considering.

Yes, I have incorporated these into the alternatives section of the proposal.  
I appreciate your suggestions!

I’ll be submitting a PR later today or tomorrow if no significant new feedback 
arises. 

>  
> 
>> extension Array: Literal.ArrayProtocol  
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 24. Juni 2016 um 17:37:27, Adrian Zubarev 
>> (adrian.zuba...@devandartist.com ) 
>> schrieb:
>> 
>>> Really? I must have overlooked that some pitched that design.
>>> 
>>> Okay now that I think through this whole scenario, I like the underscore 
>>> iff there is a good name that will be present in the final version.
>>> 
>>> When Swift 3 drops, I’ll write a proposal for nested protocols which will 
>>> refine your design (the original author went missing after pitching this 
>>> idea, and Joe Groff told me that this probably out of scope for Swift 3)!
>>> 
>>> Your current design might become this in Swift 3.X and all protocols marked 
>>> with an underscore will disappear:
>>> 
>>> public /* closed */ enum Syntax {
>>>   public protocol NilLiteral { ... }
>>>   public protocol BooleanLiteral { ... }
>>>   public protocol IntegerLiteral { ... }
>>>   public protocol FloatLiteral { ... }
>>>   public protocol UnicodeScalarLiteral { ... }
>>>   public protocol ExtendedGraphemeClusterLiteral { ... }
>>>   public protocol StringLiteralLiteral { ... }
>>>   public protocol StringInterplolationLiteral { ... }
>>>   public protocol ArrayrLiteral { ... }
>>>   public protocol DictionaryLiteral { ... }
>>> }
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 24. Juni 2016 um 17:25:45, Matthew Johnson (matt...@anandabits.com 
>>> ) schrieb:
>>> 
 The design in this proposal comes from the standard library team.  The 
 intent is for the use of underscore here to be consistent with other uses 
 of underscore prefix in the standard library.  I’m not sure why you think 
 this is different than the rest...
 
 
> On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution 
> > wrote:
> 
> I’m aware of that fact, but all types with underscore even in the stdlib 
> telling me to keep my hands of them, because something might happen to 
> them.
> 
> As an example we have _Strideable protocol which is visible by its name, 
> but its declaration isn’t visible at all:
> // FIXME(ABI)(compiler limitation): Remove `_Strideable`.
> // WORKAROUND rdar://25214598 <> - should be:
> // protocol Strideable : Comparable {...}
> 
> % for Self in ['_Strideable', 'Strideable']:
> From Stride.swift.gyb 
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matt...@anandabits.com 
> ) schrieb:
> 
>> The underscore is used in the same way it is used elsewhere in the 
>> standard library.  The protocols must be public because they need to be 
>> visible to user code in order for the design to work correctly.  
>> However, they are considered implementation details that users really 
>> shouldn’t know about.  This pattern is well established in the standard 
>> library.
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
 
>>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 

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

[Xiaodi Wu via swift-evolution]

On Fri, Jun 24, 2016 at 2:50 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jun 24, 2016, at 10:41 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> That said, how about this design:
>
> public protocol _LiteralNilProtocol { … }
> …
>
> public enum Literal {
>
> public typealias NilProtocol = …
> …
> }
>
> I’m pretty sure the standard library team intends to reserve the right to
> use this namespace for other protocols that only exist for syntactic
> support.  This may not always be literals - there may be other kinds of
> syntax supporting protocols in the future.  With that in mind I don’t think
> this design will work.
>

That said, `IntegerLiteralProtocol` or `Syntax.IntegerLiteralProtocol` both
read very nicely, IMO, so that aspect of the idea is worth considering.


>
> extension Array: Literal.ArrayProtocol
>
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 24. Juni 2016 um 17:37:27, Adrian Zubarev (
> adrian.zuba...@devandartist.com) schrieb:
>
> Really? I must have overlooked that some pitched that design.
>
> Okay now that I think through this whole scenario, I like the underscore
> iff there is a good name that will be present in the final version.
>
> When Swift 3 drops, I’ll write a proposal for nested protocols which will
> refine your design (the original author went missing after pitching this
> idea, and Joe Groff told me that this probably out of scope for Swift 3)!
>
> Your current design might become this in Swift 3.X and all protocols
> marked with an underscore will disappear:
>
> public /* closed */ enum Syntax {
>   public protocol NilLiteral { ... }
>   public protocol BooleanLiteral { ... }
>   public protocol IntegerLiteral { ... }
>   public protocol FloatLiteral { ... }
>   public protocol UnicodeScalarLiteral { ... }
>   public protocol ExtendedGraphemeClusterLiteral { ... }
>   public protocol StringLiteralLiteral { ... }
>   public protocol StringInterplolationLiteral { ... }
>   public protocol ArrayrLiteral { ... }
>   public protocol DictionaryLiteral { ... }
> }
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 24. Juni 2016 um 17:25:45, Matthew Johnson (matt...@anandabits.com)
> schrieb:
>
> The design in this proposal comes from the standard library team.  The
> intent is for the use of underscore here to be consistent with other uses
> of underscore prefix in the standard library.  I’m not sure why you think
> this is different than the rest...
>
>
> On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’m aware of that fact, but all types with underscore even in the stdlib
> telling me to keep my hands of them, because something might happen to them.
> As an example we have _Strideable protocol which is visible by its name,
> but its declaration isn’t visible at all:
>
> // FIXME(ABI)(compiler limitation): Remove `_Strideable`.
> // WORKAROUND rdar://25214598 - should be:
> // protocol Strideable : Comparable {...}
>
> % for Self in ['_Strideable', 'Strideable']:
>
> From Stride.swift.gyb
> 
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matt...@anandabits.com)
> schrieb:
>
> The underscore is used in the same way it is used elsewhere in the
> standard library.  The protocols must be public because they need to be
> visible to user code in order for the design to work correctly.  However,
> they are considered implementation details that users really shouldn’t know
> about.  This pattern is well established in the standard library.
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Fri, Jun 24, 2016 at 1:38 PM, Tony Allevato  wrote:

> 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 limits, I take it?
>>>
>>>
>>> I don’t understand why anyone wouldn’t just let Xcode do the wrapping
>>> for most cases. I’ll add newlines if I think it adds to clarity, but in
>>> general I don’t want to code like i’m still on a Wyse WY-50.
>>>
>>
>> Of course, to each their own style--I certainly wouldn't want Swift to
>> force everyone to write lines of certain lengths. But 80-character lines is
>> a common style, and I would say that a corollary of "to each their own" is
>> that Swift's grammar should be usable and useful whether or not you adhere
>> to such style choices.
>>
>> If the chief advantage of `where` is that it (quoting someone above)
>> allows one to "understand as much as possible about the control flow of
>> the loop from a single line of code," then we ought perhaps to question its
>> appropriateness when the majority of its benefits [by which I mean, based
>> on your examples and Sean's, more than half of the instances in which it is
>> used] cannot be realized in a very common coding style.
>>
>
> IMO, we shouldn't be talking about "a single line of code" so much as "a
> single cohesive construct". What's important to me isn't the line length or
> whether the "where" part has to wrap onto another line, it's the number of
> potentially divergent constructs I have to parse mentally in order to
> determine the meaning of the loop.
>
> With "for-in-where", it's three:
>
> for item(1) in someCollection(2) where someCondition(3)
>
> With the alternatives suggested using if/guard/continue/break, it's more
> than that:
>
> for item(1) in someCollection(2) {
> [if | guard...else](3) someCondition(4) {
> [continue | break](5)
> }
> }
>
> I have to be more careful now interpreting the meaning of this loop
> because both or either of if/guard or continue/break can invert its
> meaning, where was "for-in-where" is concise and clear.
>

I like this way of thinking a lot, actually. Number of divergent constructs
you have to parse. Here's the thing: I think it supports removal, not
retaining. Here's why:

For every loop you encounter, to understand its meaning you *must* look for
`break` and `continue` statements, and when they're inside `if` and `guard`
you must consider how the condition is evaluated. This is a given, a sunk
cost; I see no way they can be prohibited from the language, so these are
all things you will have to look for and mentally parse in order to
understand the behavior of a loop.

Now, if you add `where`, then that is one additional divergent construct
you must understand and parse. And moreover, since you know it exists, to
be sure you really understand what's going on you'll have to check the end
of every `for...in` statement to see if it's there. And in case the line
doesn't fit on your screen, you'll have to try scrolling to see if there's
more (or read on to the next line if you've turned on line wrapping). And
you'll have to do this for *every* `for...in` loop, where the majority
don't use `where` at all!

So, I agree with you, what's important to me as well is number of divergent
constructs I have to parse. But with the removal of `where`, the number of
divergent constructs I have to think about while reading Swift loops will
decrease, not increase.

Doing .lazy.filter{...} is slightly cleaner than this, but still suffers
> from the disadvantage that it's very easy for newcomers to leave out the
> "lazy" part and accidentally write poorly performing code, and to the
> argument that "where" is considered confusing by some users, I would argue
> that it's easier to explain how it works than why "lazy" is necessary in
> this context.
>
>
>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Jun 24, 2016, at 10:41 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> That said, how about this design:
> 
> public protocol _LiteralNilProtocol { … }
> …
> 
> public enum Literal {
>  
> public typealias NilProtocol = …
> …
> }
I’m pretty sure the standard library team intends to reserve the right to use 
this namespace for other protocols that only exist for syntactic support.  This 
may not always be literals - there may be other kinds of syntax supporting 
protocols in the future.  With that in mind I don’t think this design will work.
> extension Array: Literal.ArrayProtocol  
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 24. Juni 2016 um 17:37:27, Adrian Zubarev (adrian.zuba...@devandartist.com 
> ) schrieb:
> 
>> Really? I must have overlooked that some pitched that design.
>> 
>> Okay now that I think through this whole scenario, I like the underscore iff 
>> there is a good name that will be present in the final version.
>> 
>> When Swift 3 drops, I’ll write a proposal for nested protocols which will 
>> refine your design (the original author went missing after pitching this 
>> idea, and Joe Groff told me that this probably out of scope for Swift 3)!
>> 
>> Your current design might become this in Swift 3.X and all protocols marked 
>> with an underscore will disappear:
>> 
>> public /* closed */ enum Syntax {
>>   public protocol NilLiteral { ... }
>>   public protocol BooleanLiteral { ... }
>>   public protocol IntegerLiteral { ... }
>>   public protocol FloatLiteral { ... }
>>   public protocol UnicodeScalarLiteral { ... }
>>   public protocol ExtendedGraphemeClusterLiteral { ... }
>>   public protocol StringLiteralLiteral { ... }
>>   public protocol StringInterplolationLiteral { ... }
>>   public protocol ArrayrLiteral { ... }
>>   public protocol DictionaryLiteral { ... }
>> }
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 24. Juni 2016 um 17:25:45, Matthew Johnson (matt...@anandabits.com 
>> ) schrieb:
>> 
>>> The design in this proposal comes from the standard library team.  The 
>>> intent is for the use of underscore here to be consistent with other uses 
>>> of underscore prefix in the standard library.  I’m not sure why you think 
>>> this is different than the rest...
>>> 
>>> 
 On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution 
 > wrote:
 
 I’m aware of that fact, but all types with underscore even in the stdlib 
 telling me to keep my hands of them, because something might happen to 
 them.
 
 As an example we have _Strideable protocol which is visible by its name, 
 but its declaration isn’t visible at all:
 // FIXME(ABI)(compiler limitation): Remove `_Strideable`.
 // WORKAROUND rdar://25214598  - should be:
 // protocol Strideable : Comparable {...}
 
 % for Self in ['_Strideable', 'Strideable']:
 From Stride.swift.gyb 
 
 
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 
 Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matt...@anandabits.com 
 ) schrieb:
 
> The underscore is used in the same way it is used elsewhere in the 
> standard library.  The protocols must be public because they need to be 
> visible to user code in order for the design to work correctly.  However, 
> they are considered implementation details that users really shouldn’t 
> know about.  This pattern is well established in the standard library.
 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Jun 24, 2016, at 10:37 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Really? I must have overlooked that some pitched that design. 
> 
It wasn’t pitched in its own thread.  It came up in discussions about the 
previous proposal a couple different times.
> Okay now that I think through this whole scenario, I like the underscore iff 
> there is a good name that will be present in the final version.
> 
> When Swift 3 drops, I’ll write a proposal for nested protocols which will 
> refine your design (the original author went missing after pitching this 
> idea, and Joe Groff told me that this probably out of scope for Swift 3)!
> 
Yes, the plan is to take advantage of any relevant features Swift gets in the 
future.  This would allow removal of the underscore protocols.  If Swift gets 
submodules or real namespaces I’m sure `Syntax` would become one of those as 
well.  The good news is that all of this is considered implementation details 
that don’t affect user code so I don’t believe making these changes would 
require a proposal.
> Your current design might become this in Swift 3.X and all protocols marked 
> with an underscore will disappear:
> 
> public /* closed */ enum Syntax {
>   public protocol NilLiteral { ... }
>   public protocol BooleanLiteral { ... }
>   public protocol IntegerLiteral { ... }
>   public protocol FloatLiteral { ... }
>   public protocol UnicodeScalarLiteral { ... }
>   public protocol ExtendedGraphemeClusterLiteral { ... }
>   public protocol StringLiteralLiteral { ... }
>   public protocol StringInterplolationLiteral { ... }
>   public protocol ArrayrLiteral { ... }
>   public protocol DictionaryLiteral { ... }
> }
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 24. Juni 2016 um 17:25:45, Matthew Johnson (matt...@anandabits.com 
> ) schrieb:
> 
>> The design in this proposal comes from the standard library team.  The 
>> intent is for the use of underscore here to be consistent with other uses of 
>> underscore prefix in the standard library.  I’m not sure why you think this 
>> is different than the rest...
>> 
>> 
>>> On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution 
>>> > wrote:
>>> 
>>> I’m aware of that fact, but all types with underscore even in the stdlib 
>>> telling me to keep my hands of them, because something might happen to them.
>>> 
>>> As an example we have _Strideable protocol which is visible by its name, 
>>> but its declaration isn’t visible at all:
>>> // FIXME(ABI)(compiler limitation): Remove `_Strideable`.
>>> // WORKAROUND rdar://25214598  - should be:
>>> // protocol Strideable : Comparable {...}
>>> 
>>> % for Self in ['_Strideable', 'Strideable']:
>>> From Stride.swift.gyb 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matt...@anandabits.com 
>>> ) schrieb:
>>> 
 The underscore is used in the same way it is used elsewhere in the 
 standard library.  The protocols must be public because they need to be 
 visible to user code in order for the design to work correctly.  However, 
 they are considered implementation details that users really shouldn’t 
 know about.  This pattern is well established in the standard library.
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Collection index complexity and data structures

[David Waite via swift-evolution]

I noticed that the new Collection index(_:offsetBy:) 
 
does not define that negative offsets require a BidirectionalCollection. It 
also declares that negative offsets must complete in O( | offset | ) time. This 
differs from other methods such as distance(from:to:) 
which
 indicates start <= end if not a BidirectionalCollection

This would preclude some data structures from strictly implementing the 
Collection protocol, such as singly-linked lists.

Would it be appropriate to indicate instead that BidirectionalCollection 
defines the negative offset behavior and negative offset performance constraint?

-DW___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] UnsafeRawPointer API

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 24, 2016, at 12:58 PM, Andrew Trick  wrote:
> 
> 
>> On Jun 24, 2016, at 8:19 AM, Matthew Johnson  wrote:
>> 
>> Andrew, thank you for working on this.  The latest draft is much improved!
>> 
>> I have a few questions.
>> 
>> Why do you require explicitly passing the type in these signatures?
>> 
>> func initialize(_: T.Type, with: T, count: Int = 1) -> 
>> UnsafeMutablePointer
>> func initialize(toContiguous: T.Type, atIndex: Int, with: T) -> 
>> UnsafeMutablePointer
>> func storeRaw(_: T.Type, with: T)
>> func storeRaw(toContiguous: T.Type, atIndex: Int, with: T)
>> 
>> There is probably a good reason, but it seems redundant at first glance and 
>> isn’t obvious from my reading of the proposal.  The alternatives would be 
>> something like this:
>> 
>> func initialize(with: T, count: Int = 1) -> UnsafeMutablePointer
> 
> Good question. It is deliberately, and unfortunately redundant. We're trading 
> convenience for safety. I added this note to the proposal:
> 
> Note that the `T.Type` argument on `initialize` is redundant because
> it may be inferred from the `with` argument. However, relying on type
> inferrence at this point is dangerous. The user needs to ensure that
> the raw pointer has the necessary size and alignment for the
> initialized type. Explicitly spelling the type at initialization
> prevents bugs in which the user has incorrectly guessed the inferred
> type.

I suspected it was something like this.  Thanks for explaining and updating the 
proposal!

> 
>> The parameter order in this signature is the opposite of the order in 
>> UnsafeMutablePointer.  Is that intentional?  If so, what is the rationale?  
>> You might want to elaborate this in the proposal.
>> 
>> public func + (lhs: Int, rhs: UnsafeRawPointer) -> UnsafeRawPointer
> 
> Fixed.
> 
>> Shouldn’t the precondition be that memory for all elements is 
>> *uninitialized* / *deinitialized* in this example?
>> 
>> // - precondition: memory for all elements is initialized.
>> func freeCBuffer() {
>>   UnsafeRawPointer(ptrToA).deallocate(capacity: eltCount, of: A.self)
>> }
> 
> Typo. Thanks!
> 
>> It looks like there is a type in this example:
>> 
>> var anyT = T(...)
>> takesTPtr()
>> takesVoidPtr()
>> 
>> Should the last line say ``?
> 
> Typo. Thanks!
> 
> -Andy
> 
>> Other than these few questions all I can say is that this looks great!  I 
>> believe it will add important clarity to code that works with unsafe 
>> pointers.
>> 
>> -Matthew
>> 
>>> On Jun 23, 2016, at 8:40 PM, Andrew Trick via swift-evolution 
>>>  wrote:
>>> 
>>> 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, 
>>> and the memory model has been simplified and clarified.
>>> 
>>> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md
>>> 
>>> If you have opinions or suggestions on API syntax, please make yourself 
>>> heard. You can jump straight to the naming discussion here:
>>> 
>>> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md#variations-under-consideration
>>> 
>>> Of particular interest may be the API names for:
>>> 
>>> - Memory allocation/deallocation: fairly fundamental to the language.
>>> 
>>> - Unsafe casting from raw pointers to typed pointers. This is going to 
>>> impact a lot of code that needs C interoperability.
>>> 
>>> Keep in mind that we will make additive API improvements later for 
>>> convenience. We want the fundamentals to be clear, explicit, and reasonably 
>>> safe.
>>> 
>>> -Andy
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Fri, Jun 24, 2016 at 2:26 PM, Charlie Monroe 
wrote:

>
> On Jun 24, 2016, at 9:00 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Fri, Jun 24, 2016 at 1:56 PM, Sean Heber  wrote:
>
>> > On Jun 24, 2016, at 1:30 PM, 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 limits, I take it?
>> >
>> > I don’t understand why anyone wouldn’t just let Xcode do the wrapping
>> for most cases. I’ll add newlines if I think it adds to clarity, but in
>> general I don’t want to code like i’m still on a Wyse WY-50.
>> >
>> > Of course, to each their own style--I certainly wouldn't want Swift to
>> force everyone to write lines of certain lengths. But 80-character lines is
>> a common style, and I would say that a corollary of "to each their own" is
>> that Swift's grammar should be usable and useful whether or not you adhere
>> to such style choices.
>>
>> I honestly don’t believe that this a common style in the Cocoa community.
>
>
> We're talking about the Swift community here, and Swift stdlib would be a
> good starting point as to what is a common or at least accepted style; it
> uses 80-character lines.
>
>
> While it does, it makes sense only for readability purposes of the
> documentation. For example, I see absolute no reason why to split
> https://github.com/apple/swift/blob/master/stdlib/public/core/StringBuffer.swift#L233
>  into
> two lines.
>
> It makes the code less readable.
>
> 80-char style made sense in C, where everything is pretty much top-level.
> But given that you declare a class, within which you declare another class,
> within which you declare methods, the first level of the method indentation
> is at level 3, which given 4 spaces per tab gives you 12 characters
> already. Adding a few levels (for-cycle + an if statement within the for
> cycle) gives you 20 characters of just whitespace (1/4 of the allocated 80
> chars per line).
>
> Which is why I don't believe this code style is valid in a modern language.
>

This is one style that some very intelligent people use in Swift. I'm not
going to debate what styles are "valid."

My personal guess is that it should be upped to e.g. 160 chars per line -
> that kind of makes sense. There is no particular reason other than historic
> why we're still using 80 chars per line.
>
>
>
>> I’m not a member of the “old guard” having only come into this world 10
>> years ago with the iPhone, but just take a look at this delegate method in
>> Objective-C:
>>
>> - (void)locationManager:(CLLocationManager *)manager
>> rangingBeaconsDidFailForRegion:(CLBeaconRegion *)region withError:(NSError
>> *)error;
>>
>> That’s well over 80 characters all by itself. This fits on my screen in a
>> single line - and I work on a 15” MBP with room for my dock always visible
>> on the side along with Xcode’s sidebar open! On a typical desktop-sized
>> screen, 80-col lines must be comically short.
>>
>> I don’t know why it should be assumed that people are adhering to a
>> so-called standard that dates back to terminal screens that didn’t have
>> color.
>>
>>
>> > If the chief advantage of `where` is that it (quoting someone above)
>> allows one to "understand as much as possible about the control flow of the
>> loop from a single line of code," then we ought perhaps to question its
>> appropriateness when the majority of its benefits [by which I mean, based
>> on your examples and Sean's, more than half of the instances in which it is
>> used] cannot be realized in a very common coding style.
>>
>> Again, I dispute the idea (having no data but my own :P) that 80-col
>> limits are common in this community.
>>
>> l8r
>> Sean
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

> On Jun 22, 2016, at 5:41 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
>> I agree, names are not the primary issue.
>> 
>> Another issue is that you cannot currently write generic code that
>> might need to iterate a sequence more than once.  You currently have
>> to over-constrain types to `Collection` even if you don’t need to do
>> anything other than iterate the elements (the discussion about whether
>> `LazyFilterSequnce` has a bug in its `underestimateCount` is relevant
>> here).
> 
> That's not an over-constraint.  Multi-pass-ness *is* the fundamental
> distinction between Sequence and Collection.  AFAIK there's no multipass
> sequence that cannot support indices.

Just wanted to communicate more around this point specifically. If Collections 
can be infinite (probably adding special meaning to count returning 
Collection.IndexDistance.max), then the only difference between Sequence and 
Collection is the indexes.

However, I’m concerned about the delta between an iterator and a full 
collection. For an example:

class FibIterator : IteratorProtocol {
  var last = 0, current = 1

  func next() -> Int? {
(last, current) = (current, current + last)
return current
  }
}

If subscript indexing on collections isn't required to be an O(1) operation, I 
don’t see a reason for Sequence to exist - we can simply enumerate the sequence 
with a numeric index, and iterate up to that count to resolve. But this makes 
things surprising for those implementing generic algorithms across Collections.

I don’t see a way to get an O(1) integer index and meet all the efficiency 
constraints of Collection without either memoization or additional complexity 
on implementing FibIterator.

1. we could use integer indexes and use a non-recursive technique for 
calculating the fibonacci value at the specified index. FibIterator basically 
is rewritten into a function “fibonacci(at index:Int)”.

2. We could use a copy of FibIterator as the index, since it is a value type. 
FibIterator would need to implement Comparable.

2a. We make the index InfiniteSequenceIndex< FibIterator >, where the 
wrapper is there to define a consistent EndIndex value.

However, Collection’s index(_:offsetBy) allows for negative offsets, 
which would not be accomplished in O(n).

2b. If FibIterator gains an extra method to become bidirectional we can 
support index(_:offsetBy) in O(n) time. Note that you would probably want to 
have a bidirectional iterator define its own endIndex.

-DW


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> On Jun 24, 2016, at 9:00 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Fri, Jun 24, 2016 at 1:56 PM, Sean Heber  > wrote:
> > On Jun 24, 2016, at 1:30 PM, Xiaodi Wu via swift-evolution 
> > > 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 limits, I take it?
> >
> > I don’t understand why anyone wouldn’t just let Xcode do the wrapping for 
> > most cases. I’ll add newlines if I think it adds to clarity, but in general 
> > I don’t want to code like i’m still on a Wyse WY-50.
> >
> > Of course, to each their own style--I certainly wouldn't want Swift to 
> > force everyone to write lines of certain lengths. But 80-character lines is 
> > a common style, and I would say that a corollary of "to each their own" is 
> > that Swift's grammar should be usable and useful whether or not you adhere 
> > to such style choices.
> 
> I honestly don’t believe that this a common style in the Cocoa community.
> 
> We're talking about the Swift community here, and Swift stdlib would be a 
> good starting point as to what is a common or at least accepted style; it 
> uses 80-character lines.

While it does, it makes sense only for readability purposes of the 
documentation. For example, I see absolute no reason why to split 
https://github.com/apple/swift/blob/master/stdlib/public/core/StringBuffer.swift#L233
 

 into two lines.

It makes the code less readable.

80-char style made sense in C, where everything is pretty much top-level. But 
given that you declare a class, within which you declare another class, within 
which you declare methods, the first level of the method indentation is at 
level 3, which given 4 spaces per tab gives you 12 characters already. Adding a 
few levels (for-cycle + an if statement within the for cycle) gives you 20 
characters of just whitespace (1/4 of the allocated 80 chars per line).

Which is why I don't believe this code style is valid in a modern language. My 
personal guess is that it should be upped to e.g. 160 chars per line - that 
kind of makes sense. There is no particular reason other than historic why 
we're still using 80 chars per line.

>  
> I’m not a member of the “old guard” having only come into this world 10 years 
> ago with the iPhone, but just take a look at this delegate method in 
> Objective-C:
> 
> - (void)locationManager:(CLLocationManager *)manager 
> rangingBeaconsDidFailForRegion:(CLBeaconRegion *)region withError:(NSError 
> *)error;
> 
> That’s well over 80 characters all by itself. This fits on my screen in a 
> single line - and I work on a 15” MBP with room for my dock always visible on 
> the side along with Xcode’s sidebar open! On a typical desktop-sized screen, 
> 80-col lines must be comically short.
> 
> I don’t know why it should be assumed that people are adhering to a so-called 
> standard that dates back to terminal screens that didn’t have color.
> 
> 
> > If the chief advantage of `where` is that it (quoting someone above) allows 
> > one to "understand as much as possible about the control flow of the loop 
> > from a single line of code," then we ought perhaps to question its 
> > appropriateness when the majority of its benefits [by which I mean, based 
> > on your examples and Sean's, more than half of the instances in which it is 
> > used] cannot be realized in a very common coding style.
> 
> Again, I dispute the idea (having no data but my own :P) that 80-col limits 
> are common in this community.
> 
> l8r
> Sean
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Fri, Jun 24, 2016 at 1:56 PM, Sean Heber  wrote:

> > On Jun 24, 2016, at 1:30 PM, 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 limits, I take it?
> >
> > I don’t understand why anyone wouldn’t just let Xcode do the wrapping
> for most cases. I’ll add newlines if I think it adds to clarity, but in
> general I don’t want to code like i’m still on a Wyse WY-50.
> >
> > Of course, to each their own style--I certainly wouldn't want Swift to
> force everyone to write lines of certain lengths. But 80-character lines is
> a common style, and I would say that a corollary of "to each their own" is
> that Swift's grammar should be usable and useful whether or not you adhere
> to such style choices.
>
> I honestly don’t believe that this a common style in the Cocoa community.


We're talking about the Swift community here, and Swift stdlib would be a
good starting point as to what is a common or at least accepted style; it
uses 80-character lines.


> I’m not a member of the “old guard” having only come into this world 10
> years ago with the iPhone, but just take a look at this delegate method in
> Objective-C:
>
> - (void)locationManager:(CLLocationManager *)manager
> rangingBeaconsDidFailForRegion:(CLBeaconRegion *)region withError:(NSError
> *)error;
>
> That’s well over 80 characters all by itself. This fits on my screen in a
> single line - and I work on a 15” MBP with room for my dock always visible
> on the side along with Xcode’s sidebar open! On a typical desktop-sized
> screen, 80-col lines must be comically short.
>
> I don’t know why it should be assumed that people are adhering to a
> so-called standard that dates back to terminal screens that didn’t have
> color.
>
>
> > If the chief advantage of `where` is that it (quoting someone above)
> allows one to "understand as much as possible about the control flow of the
> loop from a single line of code," then we ought perhaps to question its
> appropriateness when the majority of its benefits [by which I mean, based
> on your examples and Sean's, more than half of the instances in which it is
> used] cannot be realized in a very common coding style.
>
> Again, I dispute the idea (having no data but my own :P) that 80-col
> limits are common in this community.
>
> l8r
> Sean
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Stephen Canon via swift-evolution]

> On Jun 24, 2016, at 2:52 PM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 24 Jun 2016, at 18:17, Károly Lőrentey via swift-evolution 
>>  wrote:
>> I’m especially stoked about `FixedWidthInteger.doubleWidthMultiply`, which 
>> will likely lead to a measurable speedup. Why is there no 
>> `doubleWidthQuotientAndRemainder` or `doubleWidthDivide`, though?
> 
> Double-width isn't needed for these as it's impossible for an integer to 
> become larger when dividing (the smallest value you can divide by and get a 
> result is 2, which will halve the value), and the remainder can't be larger 
> than the original value.

A double-width divide takes a double-width *numerator*, and is a useful 
building block for some approaches to bignum divides.

– Steve
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Károly Lőrentey via swift-evolution]

The operation I want is the inverse of doubleWidthMultiply, where you have a 
(high, low) word pair and you want to divide it by a single word, getting a 
quotient and remainder. This is an important building block for implementing 
arbitrary precision division. Intel’s DIV can do this in a single instruction, 
while doing it in code requires a lot of work:

https://github.com/lorentey/BigInt/blob/swift3/Sources/BigDigit.swift#L119-L176

> On 2016-06-24, at 20:52, Haravikk  wrote:
> 
> 
>> On 24 Jun 2016, at 18:17, Károly Lőrentey via swift-evolution 
>>  wrote:
>> I’m especially stoked about `FixedWidthInteger.doubleWidthMultiply`, which 
>> will likely lead to a measurable speedup. Why is there no 
>> `doubleWidthQuotientAndRemainder` or `doubleWidthDivide`, though?
> 
> Double-width isn't needed for these as it's impossible for an integer to 
> become larger when dividing (the smallest value you can divide by and get a 
> result is 2, which will halve the value), and the remainder can't be larger 
> than the original value.
> 
> 
> Anyway, I'm hugely in favour of this proposal, it's desperately needed!

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Fri, Jun 24, 2016 at 1:38 PM, Tony Allevato  wrote:

> 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 limits, I take it?
>>>
>>>
>>> I don’t understand why anyone wouldn’t just let Xcode do the wrapping
>>> for most cases. I’ll add newlines if I think it adds to clarity, but in
>>> general I don’t want to code like i’m still on a Wyse WY-50.
>>>
>>
>> Of course, to each their own style--I certainly wouldn't want Swift to
>> force everyone to write lines of certain lengths. But 80-character lines is
>> a common style, and I would say that a corollary of "to each their own" is
>> that Swift's grammar should be usable and useful whether or not you adhere
>> to such style choices.
>>
>> If the chief advantage of `where` is that it (quoting someone above)
>> allows one to "understand as much as possible about the control flow of
>> the loop from a single line of code," then we ought perhaps to question its
>> appropriateness when the majority of its benefits [by which I mean, based
>> on your examples and Sean's, more than half of the instances in which it is
>> used] cannot be realized in a very common coding style.
>>
>
> IMO, we shouldn't be talking about "a single line of code" so much as "a
> single cohesive construct". What's important to me isn't the line length or
> whether the "where" part has to wrap onto another line, it's the number of
> potentially divergent constructs I have to parse mentally in order to
> determine the meaning of the loop.
>
> With "for-in-where", it's three:
>
> for item(1) in someCollection(2) where someCondition(3)
>
> With the alternatives suggested using if/guard/continue/break, it's more
> than that:
>
> for item(1) in someCollection(2) {
> [if | guard...else](3) someCondition(4) {
> [continue | break](5)
> }
> }
>
> I have to be more careful now interpreting the meaning of this loop
> because both or either of if/guard or continue/break can invert its
> meaning, where was "for-in-where" is concise and clear.
>

And if `while` is added along with `where`, all this goes out the window.


> Doing .lazy.filter{...} is slightly cleaner than this, but still suffers
> from the disadvantage that it's very easy for newcomers to leave out the
> "lazy" part and accidentally write poorly performing code, and to the
> argument that "where" is considered confusing by some users, I would argue
> that it's easier to explain how it works than why "lazy" is necessary in
> this context.
>

Clearly, eagerly filtering results in slower code, but based on the
examples provided above I don't imagine any of them would turn into "poorly
performing" code with eager filtering. In fact, I see some that could run a
little faster with some refactoring along these lines. In any case,
optimizing performance comes after correctness; a user who can't grasp
`lazy` can nonetheless still write useful, correct code.

 ___

> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Sean Heber via swift-evolution]

> On Jun 24, 2016, at 1:30 PM, Xiaodi Wu via swift-evolution 
>  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 limits, I take it?
> 
> I don’t understand why anyone wouldn’t just let Xcode do the wrapping for 
> most cases. I’ll add newlines if I think it adds to clarity, but in general I 
> don’t want to code like i’m still on a Wyse WY-50.
> 
> Of course, to each their own style--I certainly wouldn't want Swift to force 
> everyone to write lines of certain lengths. But 80-character lines is a 
> common style, and I would say that a corollary of "to each their own" is that 
> Swift's grammar should be usable and useful whether or not you adhere to such 
> style choices.

I honestly don’t believe that this a common style in the Cocoa community. I’m 
not a member of the “old guard” having only come into this world 10 years ago 
with the iPhone, but just take a look at this delegate method in Objective-C:

- (void)locationManager:(CLLocationManager *)manager 
rangingBeaconsDidFailForRegion:(CLBeaconRegion *)region withError:(NSError 
*)error;

That’s well over 80 characters all by itself. This fits on my screen in a 
single line - and I work on a 15” MBP with room for my dock always visible on 
the side along with Xcode’s sidebar open! On a typical desktop-sized screen, 
80-col lines must be comically short.

I don’t know why it should be assumed that people are adhering to a so-called 
standard that dates back to terminal screens that didn’t have color.


> If the chief advantage of `where` is that it (quoting someone above) allows 
> one to "understand as much as possible about the control flow of the loop 
> from a single line of code," then we ought perhaps to question its 
> appropriateness when the majority of its benefits [by which I mean, based on 
> your examples and Sean's, more than half of the instances in which it is 
> used] cannot be realized in a very common coding style.

Again, I dispute the idea (having no data but my own :P) that 80-col limits are 
common in this community.

l8r
Sean

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 24 Jun 2016, at 18:17, Károly Lőrentey via swift-evolution 
>  wrote:
> I’m especially stoked about `FixedWidthInteger.doubleWidthMultiply`, which 
> will likely lead to a measurable speedup. Why is there no 
> `doubleWidthQuotientAndRemainder` or `doubleWidthDivide`, though?

Double-width isn't needed for these as it's impossible for an integer to become 
larger when dividing (the smallest value you can divide by and get a result is 
2, which will halve the value), and the remainder can't be larger than the 
original value.


Anyway, I'm hugely in favour of this proposal, it's desperately needed!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tony Allevato via swift-evolution]

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 limits, I take it?
>>
>>
>> I don’t understand why anyone wouldn’t just let Xcode do the wrapping for
>> most cases. I’ll add newlines if I think it adds to clarity, but in general
>> I don’t want to code like i’m still on a Wyse WY-50.
>>
>
> Of course, to each their own style--I certainly wouldn't want Swift to
> force everyone to write lines of certain lengths. But 80-character lines is
> a common style, and I would say that a corollary of "to each their own" is
> that Swift's grammar should be usable and useful whether or not you adhere
> to such style choices.
>
> If the chief advantage of `where` is that it (quoting someone above)
> allows one to "understand as much as possible about the control flow of
> the loop from a single line of code," then we ought perhaps to question its
> appropriateness when the majority of its benefits [by which I mean, based
> on your examples and Sean's, more than half of the instances in which it is
> used] cannot be realized in a very common coding style.
>

IMO, we shouldn't be talking about "a single line of code" so much as "a
single cohesive construct". What's important to me isn't the line length or
whether the "where" part has to wrap onto another line, it's the number of
potentially divergent constructs I have to parse mentally in order to
determine the meaning of the loop.

With "for-in-where", it's three:

for item(1) in someCollection(2) where someCondition(3)

With the alternatives suggested using if/guard/continue/break, it's more
than that:

for item(1) in someCollection(2) {
[if | guard...else](3) someCondition(4) {
[continue | break](5)
}
}

I have to be more careful now interpreting the meaning of this loop because
both or either of if/guard or continue/break can invert its meaning, where
was "for-in-where" is concise and clear.

Doing .lazy.filter{...} is slightly cleaner than this, but still suffers
from the disadvantage that it's very easy for newcomers to leave out the
"lazy" part and accidentally write poorly performing code, and to the
argument that "where" is considered confusing by some users, I would argue
that it's easier to explain how it works than why "lazy" is necessary in
this context.



> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 limits, I take it?
>
>
> I don’t understand why anyone wouldn’t just let Xcode do the wrapping for
> most cases. I’ll add newlines if I think it adds to clarity, but in general
> I don’t want to code like i’m still on a Wyse WY-50.
>

Of course, to each their own style--I certainly wouldn't want Swift to
force everyone to write lines of certain lengths. But 80-character lines is
a common style, and I would say that a corollary of "to each their own" is
that Swift's grammar should be usable and useful whether or not you adhere
to such style choices.

If the chief advantage of `where` is that it (quoting someone above) allows
one to "understand as much as possible about the control flow of the loop
from a single line of code," then we ought perhaps to question its
appropriateness when the majority of its benefits [by which I mean, based
on your examples and Sean's, more than half of the instances in which it is
used] cannot be realized in a very common coding style.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] UnsafeRawPointer API

[John McCall via swift-evolution]

> On Jun 24, 2016, at 10:58 AM, Andrew Trick via swift-evolution 
>  wrote:
>> On Jun 24, 2016, at 8:19 AM, Matthew Johnson > > wrote:
>> 
>> Andrew, thank you for working on this.  The latest draft is much improved!
>> 
>> I have a few questions.
>> 
>> Why do you require explicitly passing the type in these signatures?
>> 
>> func initialize(_: T.Type, with: T, count: Int = 1) -> 
>> UnsafeMutablePointer
>> func initialize(toContiguous: T.Type, atIndex: Int, with: T) -> 
>> UnsafeMutablePointer
>> func storeRaw(_: T.Type, with: T)
>> func storeRaw(toContiguous: T.Type, atIndex: Int, with: T)
>> 
>> There is probably a good reason, but it seems redundant at first glance and 
>> isn’t obvious from my reading of the proposal.  The alternatives would be 
>> something like this:
>> 
>> func initialize(with: T, count: Int = 1) -> UnsafeMutablePointer
> 
> Good question. It is deliberately, and unfortunately redundant. We're trading 
> convenience for safety. I added this note to the proposal:
> 
> Note that the `T.Type` argument on `initialize` is redundant because
> it may be inferred from the `with` argument. However, relying on type
> inferrence at this point is dangerous. The user needs to ensure that
> the raw pointer has the necessary size and alignment for the
> initialized type. Explicitly spelling the type at initialization
> prevents bugs in which the user has incorrectly guessed the inferred
> type.

One major problematic case: the value could have a defaulted type, e.g.:
  pointer.initialize(with: 0, count: 1024)

John.

> 
>> The parameter order in this signature is the opposite of the order in 
>> UnsafeMutablePointer.  Is that intentional?  If so, what is the rationale?  
>> You might want to elaborate this in the proposal.
>> 
>> public func + (lhs: Int, rhs: UnsafeRawPointer) -> UnsafeRawPointer
> 
> Fixed.
> 
>> Shouldn’t the precondition be that memory for all elements is 
>> *uninitialized* / *deinitialized* in this example?
>> 
>> // - precondition: memory for all elements is initialized.
>> func freeCBuffer() {
>>   UnsafeRawPointer(ptrToA).deallocate(capacity: eltCount, of: A.self)
>> }
>> 
> 
> Typo. Thanks!
> 
>> It looks like there is a type in this example:
>> 
>> var anyT = T(...)
>> takesTPtr()
>> takesVoidPtr()
>> 
>> Should the last line say ``?
> 
> Typo. Thanks!
> 
> -Andy
> 
>> Other than these few questions all I can say is that this looks great!  I 
>> believe it will add important clarity to code that works with unsafe 
>> pointers.
>> 
>> -Matthew
>> 
>>> On Jun 23, 2016, at 8:40 PM, Andrew Trick via swift-evolution 
>>> > wrote:
>>> 
>>> 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, 
>>> and the memory model has been simplified and clarified.
>>> 
>>> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md
>>>  
>>> 
>>> 
>>> If you have opinions or suggestions on API syntax, please make yourself 
>>> heard. You can jump straight to the naming discussion here:
>>> 
>>> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md#variations-under-consideration
>>>  
>>> 
>>> 
>>> Of particular interest may be the API names for:
>>> 
>>> - Memory allocation/deallocation: fairly fundamental to the language.
>>> 
>>> - Unsafe casting from raw pointers to typed pointers. This is going to 
>>> impact a lot of code that needs C interoperability.
>>> 
>>> Keep in mind that we will make additive API improvements later for 
>>> convenience. We want the fundamentals to be clear, explicit, and reasonably 
>>> safe.
>>> 
>>> -Andy
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

> On Jun 23, 2016, at 23:06, Nicola Salmoria via swift-evolution 
>  wrote:
> 
> 
> 
> On Fri, Jun 24, 2016 at 12:12 AM, Max Moiseev  > wrote:
> 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 that remainder is special, let me see what I can do about it.
> 
> 
> LOL, yes of course, I forgot about the obvious trapping case.
> 
> However, division by 0 isn't an overflow: it's an undefined operation. I find 
> it somewhat surprising that dividedWithOverflow/remainderWithOverflow allow 
> attempting this operation.
> 
> To me, the intuitive semantics of the WithOverflow methods are "perform the 
> operation, and if the result doesn't fit in the given type, return a 
> truncated result and an overflow flag". This is not what happens when 
> dividing by 0, because the result simply doesn't exist.
> 
> I think I would prefer if rhs != 0 was documented as an explicit precondition 
> of the division and remainder operations, and 
> dividedWithOverflow/remainderWithOverflow trapped because of precondition 
> failure.
> 
> If it is desirable that the WithOverflow methods never trap, then I think it 
> would be better to add a `divisionByZero` case to the ArithmeticOverflow enum 
> and return that instead of the generic `overflow`.

IIUC, the WithOverflow flag is only for the INT_MIN / -1 case. (And IIUC, that 
doesn't affect remainder.)

Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] UnsafeRawPointer API

[Andrew Trick via swift-evolution]

> On Jun 24, 2016, at 11:17 AM, L. Mihalkovic  
> wrote:
> 
> I like the watch-what-you-wish-for warning of unsafeCast.

I’ll try porting stdlib to the “UnsafeRawPointer.unsafeCast(to: T.Type)” syntax 
and see how bad it is.

> I think it was really brilliant to introduce the extra step... basically 
> echos the alloc/init dichotomy of objc, so it should feel familiar to people 
> with this 

Dave Abrahams advocated for this and it ended up making the memory model easier 
to explain in simple terms that correspond to the API.

-Andy___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] UnsafeRawPointer API

[L. Mihalkovic via swift-evolution]

> On Jun 24, 2016, at 7:43 PM, Andrew Trick  wrote:
> 
> 
>> On Jun 23, 2016, at 10:10 PM, L. Mihalkovic  
>> wrote:
>> 
>> Very cool...
>> 
>> Couple thoughts
>> 
>> UnsafeMutableRawPointer:
>> func store(, WITH: T)
>> does not flow very well
>> Fill:with: seems nicer or write(, from:T) which means changing 'load' into 
>> 'read'
>> func read(_ : T.Type) -> T
>> func write(_: T.T.Type, from: T) (write even match the method doc)
> 
> Yes but...
> 
> - I was parrotting the current initialize(_: T.Type, with: T) style.
> 
> - I was trying to establish consistency that `from` is used to copy from a 
> pointer which points to a range of elements.
> 
> - Doesn't `fill` imply assigning a range of elements? That would make sense 
> for `storeRaw(contiguous:)` but not the others.
> 
> - `store` by itself may imply assignment. Any previous value will not be 
> destroyed (we don't even know its type). The user needs to be aware of this, 
> at the expense of awkward naming. Safety is more important than convenience 
> here. Hence we need `storeRaw` or `storeBits`. There is a deliberate 
> assymetry between store and load because `load` will initialize its returned 
> value. `store` will not initialize the stored value. `initialize` should be 
> used for that.
> 
> - `writeRaw` sounds a little weird. `writeBits` sounds better.

all makes sense.

>> UnsafeRawPointer.toType():
>> Should it nit be something like typed(as:) instead
> 
> I like "typed(as:)" better than toType(_). I'm debating whether it should be:
> "unsafeCast(toType:)". It's a clarity/safety vs. verbosity tradeoff.

I like the watch-what-you-wish-for warning of unsafeCast.

I think it was really brilliant to introduce the extra step... basically echos 
the alloc/init dichotomy of objc, so it should feel familiar to people with 
this bkgnd

> -Andy
> 
>> Regards
>> LM
>> (From mobile)
>> 
>>> On Jun 24, 2016, at 3:40 AM, Andrew Trick via swift-evolution 
>>>  wrote:
>>> 
>>> 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, 
>>> and the memory model has been simplified and clarified.
>>> 
>>> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md
>>> 
>>> If you have opinions or suggestions on API syntax, please make yourself 
>>> heard. You can jump straight to the naming discussion here:
>>> 
>>> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md#variations-under-consideration
>>> 
>>> Of particular interest may be the API names for:
>>> 
>>> - Memory allocation/deallocation: fairly fundamental to the language.
>>> 
>>> - Unsafe casting from raw pointers to typed pointers. This is going to 
>>> impact a lot of code that needs C interoperability.
>>> 
>>> Keep in mind that we will make additive API improvements later for 
>>> convenience. We want the fundamentals to be clear, explicit, and reasonably 
>>> safe.
>>> 
>>> -Andy
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Jun 24, 2016, at 11:26 AM, Karl Wagner via swift-evolution 
>  wrote:
> 
> -1
> 
> I've followed this discussion since the beginning, and I feel the usage is 
> clear given that for...in is a *data-driven* loop
> 
> I wouldn't mind renaming to "if" if there is some confusion, but I think we 
> use "where" consistently in the language (and Dave Abrahams proposal for 
> closure argument names takes this further), so could be argued that it's 
> already clear.
> 
> Perhaps we should use "where" consistently for data-filtering operations, and 
> possibly rename the generic constraint specifier. If we wanted to be really 
> rigorously consistent.
> 
> Karl

I'd much rather keep `where` for protocol constraints and rename data-filtering 
in for-in if kept. My suggestions in the proposal are "if", "unless", "until", 
and "while". 

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] UnsafeRawPointer API

[Andrew Trick via swift-evolution]

> On Jun 24, 2016, at 8:19 AM, Matthew Johnson  wrote:
> 
> Andrew, thank you for working on this.  The latest draft is much improved!
> 
> I have a few questions.
> 
> Why do you require explicitly passing the type in these signatures?
> 
> func initialize(_: T.Type, with: T, count: Int = 1) -> 
> UnsafeMutablePointer
> func initialize(toContiguous: T.Type, atIndex: Int, with: T) -> 
> UnsafeMutablePointer
> func storeRaw(_: T.Type, with: T)
> func storeRaw(toContiguous: T.Type, atIndex: Int, with: T)
> 
> There is probably a good reason, but it seems redundant at first glance and 
> isn’t obvious from my reading of the proposal.  The alternatives would be 
> something like this:
> 
> func initialize(with: T, count: Int = 1) -> UnsafeMutablePointer

Good question. It is deliberately, and unfortunately redundant. We're trading 
convenience for safety. I added this note to the proposal:

Note that the `T.Type` argument on `initialize` is redundant because
it may be inferred from the `with` argument. However, relying on type
inferrence at this point is dangerous. The user needs to ensure that
the raw pointer has the necessary size and alignment for the
initialized type. Explicitly spelling the type at initialization
prevents bugs in which the user has incorrectly guessed the inferred
type.

> The parameter order in this signature is the opposite of the order in 
> UnsafeMutablePointer.  Is that intentional?  If so, what is the rationale?  
> You might want to elaborate this in the proposal.
> 
> public func + (lhs: Int, rhs: UnsafeRawPointer) -> UnsafeRawPointer

Fixed.

> Shouldn’t the precondition be that memory for all elements is *uninitialized* 
> / *deinitialized* in this example?
> 
> // - precondition: memory for all elements is initialized.
> func freeCBuffer() {
>   UnsafeRawPointer(ptrToA).deallocate(capacity: eltCount, of: A.self)
> }
> 

Typo. Thanks!

> It looks like there is a type in this example:
> 
> var anyT = T(...)
> takesTPtr()
> takesVoidPtr()
> 
> Should the last line say ``?

Typo. Thanks!

-Andy

> Other than these few questions all I can say is that this looks great!  I 
> believe it will add important clarity to code that works with unsafe pointers.
> 
> -Matthew
> 
>> On Jun 23, 2016, at 8:40 PM, Andrew Trick via swift-evolution 
>> > wrote:
>> 
>> 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, and the 
>> memory model has been simplified and clarified.
>> 
>> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md
>>  
>> 
>> 
>> If you have opinions or suggestions on API syntax, please make yourself 
>> heard. You can jump straight to the naming discussion here:
>> 
>> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md#variations-under-consideration
>> 
>> Of particular interest may be the API names for:
>> 
>> - Memory allocation/deallocation: fairly fundamental to the language.
>> 
>> - Unsafe casting from raw pointers to typed pointers. This is going to 
>> impact a lot of code that needs C interoperability.
>> 
>> Keep in mind that we will make additive API improvements later for 
>> convenience. We want the fundamentals to be clear, explicit, and reasonably 
>> safe.
>> 
>> -Andy
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] UnsafeRawPointer API

[Andrew Trick via swift-evolution]

> On Jun 23, 2016, at 10:10 PM, L. Mihalkovic  
> wrote:
> 
> Very cool...
> 
> Couple thoughts
> 
> UnsafeMutableRawPointer:
> func store(, WITH: T)
> does not flow very well
> Fill:with: seems nicer or write(, from:T) which means changing 'load' into 
> 'read'
> func read(_ : T.Type) -> T
> func write(_: T.T.Type, from: T) (write even match the method doc)

Yes but...

- I was parrotting the current initialize(_: T.Type, with: T) style.

- I was trying to establish consistency that `from` is used to copy from a 
pointer which points to a range of elements.

- Doesn't `fill` imply assigning a range of elements? That would make sense for 
`storeRaw(contiguous:)` but not the others.

- `store` by itself may imply assignment. Any previous value will not be 
destroyed (we don't even know its type). The user needs to be aware of this, at 
the expense of awkward naming. Safety is more important than convenience here. 
Hence we need `storeRaw` or `storeBits`. There is a deliberate assymetry 
between store and load because `load` will initialize its returned value. 
`store` will not initialize the stored value. `initialize` should be used for 
that.

- `writeRaw` sounds a little weird. `writeBits` sounds better.

> UnsafeRawPointer.toType():
> Should it nit be something like typed(as:) instead 

I like "typed(as:)" better than toType(_). I'm debating whether it should be:
"unsafeCast(toType:)". It's a clarity/safety vs. verbosity tradeoff.

-Andy

> Regards
> LM
> (From mobile)
> 
>> On Jun 24, 2016, at 3:40 AM, Andrew Trick via swift-evolution 
>>  wrote:
>> 
>> 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, and the 
>> memory model has been simplified and clarified.
>> 
>> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md
>> 
>> If you have opinions or suggestions on API syntax, please make yourself 
>> heard. You can jump straight to the naming discussion here:
>> 
>> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md#variations-under-consideration
>> 
>> Of particular interest may be the API names for:
>> 
>> - Memory allocation/deallocation: fairly fundamental to the language.
>> 
>> - Unsafe casting from raw pointers to typed pointers. This is going to 
>> impact a lot of code that needs C interoperability.
>> 
>> Keep in mind that we will make additive API improvements later for 
>> convenience. We want the fundamentals to be clear, explicit, and reasonably 
>> safe.
>> 
>> -Andy
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Karl Wagner via swift-evolution]

 
 
-1
 

 
I've followed this discussion since the beginning, and I feel the usage is 
clear given that for...in is a *data-driven* loop
 

 
I wouldn't mind renaming to "if" if there is some confusion, but I think we use 
"where" consistently in the language (and Dave Abrahams proposal for closure 
argument names takes this further), so could be argued that it's already clear.
 

 
Perhaps we should use "where" consistently for data-filtering operations, and 
possibly rename the generic constraint specifier. If we wanted to be really 
rigorously consistent.
 

 
Karl
 

 
 
 Sent from my new   Email 
(https://itunes.apple.com/app/apple-store/id922793622?pt=814382=8=my_new_email)
 
 
 
 

 
 
>  
> On Jun 23, 2016 at 6:12 AM,   (mailto:swift-evolution@swift.org)>  wrote:
>  
>  
>  
>  Hello Swift community,
>
> The review of "SE-0105: Removing Where Clauses from For-In Loops" begins now 
> and runs  through June 29. (x-apple-data-detectors://1)  The proposal is 
> available here:
>
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.md
>  
> (https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.mdReviews)
>
> Reviews 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.mdReviews)
>   are an important part of the Swift evolution process. All reviews should be 
> sent to the swift-evolution mailing list at
>
>   https://lists.swift.org/mailman/listinfo/swift-evolution 
> (https://lists.swift.org/mailman/listinfo/swift-evolutionor)
>
> or (https://lists.swift.org/mailman/listinfo/swift-evolutionor), if you would 
> like to keep your feedback private, directly to the review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve  the proposal 
> (x-apple-data-detectors://4)  under review through constructive criticism and 
> contribute to the direction of Swift. When writing your review, here are some 
> questions you might want to answer in your review:
>
>  * What is your evaluation of the proposal?
>  * Is the problem being addressed significant enough to warrant a change to 
> Swift?
>  * Does this proposal fit well with the feel and direction of Swift?
>  * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
>  * How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
>
> More information about the Swift evolution process is available at
>
>   https://github.com/apple/swift-evolution/blob/master/process.md 
> (https://github.com/apple/swift-evolution/blob/master/process.mdThank)
>
> Thank (https://github.com/apple/swift-evolution/blob/master/process.mdThank)  
> you,
>
> -Chris Lattner
> Review Manager
>
>
> ___
> swift-evolution mailing  list (mailto:listswift-evolution@swift.orghttps)
> swift-evolution@swift.org (mailto:listswift-evolution@swift.orghttps)
> https 
> (mailto:listswift-evolution@swift.orghttps)://lists.swift.org/mailman/listinfo/swift-evolution
>  ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Károly Lőrentey via swift-evolution]

> * What is your evaluation of the proposal?
+1 in general
> * Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes.
> * Does this proposal fit well with the feel and direction of Swift?
Yes, with some nitpicks detailed below.
> * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
-
> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

An afternoon of detailed study.


As the author of a Swift package for arbitrary integers 
(https://github.com/lorentey/BigInt), I’m delighted by this proposal.

I’m especially stoked about `FixedWidthInteger.doubleWidthMultiply`, which will 
likely lead to a measurable speedup. Why is there no 
`doubleWidthQuotientAndRemainder` or `doubleWidthDivide`, though?

What is the intended behavior for `nthWord` for negative numbers? Can we 
prevent having to answer this question by e.g. moving this method down to 
UnsignedInteger? Big integer libs often use a signed magnitude representation; 
having to e.g. convert it to two’s complement on the fly to satisfy the API 
would be weird. (Also, the name `nthWord` seems unswifty to me.)

Like others on this list, I also find signBitIndex confusing. The name does not 
make much sense for unsigned integers, or signed integers that do not use an 
embedded sign bit. Is it supposed to return the width (in bits) of the binary 
representation of the integer’s absolute value? (Why -1 for zero, then? What’s 
the signBitIndex for 1?) 

I can’t find any mention of the unary bitwise not (~) operation. It should be 
in FixedWidthInteger, right?

Binary bitwise operations (or/and/xor) are in FixedWidthInteger, but I believe 
they can be implemented on big integers in a way that is perfectly consistent 
with fixed width integers. Admittedly, I don’t know of any generic algorithms 
that want these.

To support big integers better, I think IntegerLiteralConvertible should also 
be updated at some point to work in terms of machine words. (Having to 
implement StringLiteralConvertible to provide source-level support for huge 
numbers works, but it isn’t great.)

I can see myself typing foo.absoluteValue instead of abs(foo) all the time; if 
its use is to be discouraged, perhaps a less prominent name would be better.

There is a typo in the Operators section: “Arithmetic” should read “Integer” in 
these two lines:

public func % (lhs: T, rhs: T) -> T
public func %= (lhs: inout T, rhs: T)

Remark: The gyb is nice when used in moderation, but I find parts of the 
prototype overuse templating to a point that’s bordering on obfuscation. E.g., 
I found this code especially hard to read:


https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L1016-L1033
 


-- 
Karoly
@lorentey


> On 2016-06-23, at 02:52, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0104: Protocol-oriented integers" begins now and runs 
> through June 27. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
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

[L Mihalkovic via swift-evolution]

Swift is all about values and protocols, so I was thinking about smthg like 
this:

enum OperatorAssociativity { case left, right }
enum PrecedenceGroup {
casedefaultGroup(OperatorAssociativity)
indirect case strongerThan(OperatorAssociativity,PrecedenceGroup)
indirect case weakerThan(OperatorAssociativity,PrecedenceGroup)
indirect case between(OperatorAssociativity, strongerThan: PrecedenceGroup, 
weakerThan: PrecedenceGroup)
}

let Additive: PrecedenceGroup = .defaultGroup(.left)
let Multiplicative: PrecedenceGroup = .strongerThan(.left, Additive)
let Exponentiative: PrecedenceGroup = .strongerThan(.left, Multiplicative)
let SomeOtherGroup: PrecedenceGroup = .between(.right, strongerThan: 
Multiplicative, weakerThan: Exponentiative)


standard Swift, which makes it easier to reflect when the api gets created in 
4.0

Regards
LM
(From mobile)


> On Jun 24, 2016, at 2:47 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> L. Mihalkovic via swift-evolution  writes:
> 
>>> Could you please explain what you mean by "meta-circular syntax for 
> the 
>>> precedence group definitions"? An example?
>> =define it using existing swift constructs rather than by extending 
> swift with new kwd looks like grp
>> matches a struct. 
> 
> I still don't fully understand without an example :(
> If you mean something like this:
> 
> protocol PrecedenceGroup_Additive {
>associatedtype StrongerThan_Comparative
>associatedtype WeakerThan_Multiplicative
> }
> 
> Then this is just ugly.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

On 24.06.2016 19:22, Paul Cantrell via swift-evolution wrote:

Way back when, there was an unresolved discussion was about whether it’s
a bug or a feature that $0 sometimes captures a single arg and sometimes
captures all args as a tuple:


Just recently I started a new thread for that subject : "[Discussion] 
func/closure parameters and tuples" but no replies for it yet. Was planing 
to start the proposal thread.


I believe we should add consistency in Swift regarding allowed arguments of 
closure/func.

Dropped questions regarding this here:
https://bugs.swift.org/browse/SR-1334
https://bugs.swift.org/browse/SR-1854

So I'll repeat questions/issues here in one place:

1. I was not expecting this will compile :

let ft1 : (Int,Int) -> Void = { x in print(x.0, x.1)}

ft1(1, 2)

the type of ft1 is definitely not the same as closure


2. The same. But this crashes compiler at compile time(bug is reported) :

let ft2 : (Int,Int) -> Void = { x in print(x) }

ft2(1, 2)

3. Was expecting closure will require a single argument, which is tuple; 
but it accepts even just x, y


typealias IntInt = (Int,Int)

func foo(block: (IntInt) -> Void) {
let z : IntInt = (1,2)
block(z)
}

foo { x in print(x)} // ok
foo { x, y in print(x,y)}
foo { (x, y) in print(x, y)}

I'm not sending two values to closure, I send one instance which is tuple.


4.

typealias BinaryIntOp_v1 = (Int, Int) -> Int
typealias BinaryIntOp_v2 = ((Int, Int)) -> Int

print(BinaryIntOp_v2.self) // Prints ((Int, Int)) -> Int  why?
print(BinaryIntOp_v2.self) // Prints ((Int, Int)) -> Int

let areRepresentingTheSameType = BinaryIntOp_v1.self == BinaryIntOp_v2.self 
// (alt-click the "==" and read doc.)

print(areRepresentingTheSameType) // Prints true

let add_v1: BinaryIntOp_v1 = (+)
let add_v2: BinaryIntOp_v2 = (+) // Or both could have been eg: { return $0 
+ $1 }


let ra = add_v1(1, 2)
let rb = add_v2((1, 2)) // NOTE: Needs these extra parens (otherwise error: 
"Extra argument in call")


let rc = (add_v1 as BinaryIntOp_v2)((1, 2)) // NOTE: I am type casting 
these to an identical type ...
let rd = (add_v2 as BinaryIntOp_v1)(1, 2)   // ... in order to swap which 
one of them need extra parens ...




http://thread.gmane.org/gmane.comp.lang.swift.evolution/3915/
https://bugs.swift.org/browse/SR-586

I mention this because it would be a breaking change to make $0
consistently capture the first arg, and I wonder whether that should be
in the Swift 3?

(If anybody wants to comment on the question, I recommend catching up on
the discussion in the links above first.)

Cheers, P



On Jun 22, 2016, at 8:07 PM, Chris Lattner via swift-evolution
 wrote:

Hi everyone,

Here is a partial list of the open topics that the core team would
like to get resolved in Swift 3.  The list is partial both because I’m
way behind on swift-evolution traffic, but also because new things may
come up.  There are also a number of accepted proposals that are not
yet implemented.  Some topics have proposals done, and therefore have
an SE number, but the review discussion hasn’t finalized.  Some of
these topics have an “owner” that is driving or planning to start a
discussion on them them, which I’ve listed in square brackets.

If you’d like to discuss these topics in particular, please start a
new thread specific to them, or contribute to an already-existing
thread discussing it.  Several of these don’t have an owner yet, so if
you’d like to pick them up and run with them, that would be great.
Thanks!

-Chris


Language: - SE-0091: Improving operator requirements in protocols
[Core team discussed this, will email about it shortly] - SE-0077:
Improve operator declaration syntax [Core team discussed this, Joe
Groff will follow up on this soon] - SE-0095: Replace protocol
syntax with P1 & P2 syntax - SE-0102: Remove @noreturn attribute and
introduce an empty NoReturn type - SE-0103: Invert @noescape - Remove
T -> T? implicit promotion for operands to operators - Removing
argument labels from the type system (so they are declaration-only
constructs) - Some reshuffling with requiring @objc/@nonobjc for
things that shouldn’t/can’t be expressed via the Objective-C runtime -
Eliminating inference of associated type witnesses (as is mentioned in
the generics manifesto) - Should public classes be
non-publicly-subclassable by default? [John McCall] - Revising access
modifiers on extensions [Adrian Zubarev]


Standard library: - SE-0101: Rename sizeof and related functions to
comply with API Guidelines - Ongoing API naming adjustments for
stdlib: - Closure arguments [Dave Abrahams] - Others are being
discussed on swift-evolution. - Remove Boolean protocol. - SE-0104:
Revise Integer protocols to match FP ones. [Max Moiseev]

SDK / Cocoa / ObjC interop: - [SE-0086] Finalize NS removal plan.
[Tony Parker] - Importing “id” as Any [Joe Groff] - Revise
NSError/Error model for better interoperability and usability. [Doug
Gregor] -  Bridge NSRange to “Range?”

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

[Austin Zheng via swift-evolution]

> On Jun 24, 2016, at 9:04 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On Jun 23, 2016, at 22:20, L. Mihalkovic > > wrote:
>> 
>> This is another way to generalize P compositions that opens another way to 
>> specify WHERE
>> 
>> https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051 
>> 
> Thanks for bringing this up. I know one reason we’ve avoided syntax like this 
> in the past is the potential for static subscripts, but of course that’s just 
> one of many future concerns.

I would prefer to simply expand `<...>` to refer to type arguments in general, 
rather than simply generic arguments, and keep the `Any` syntax. The argument 
made by a few people in the previous thread that `<...>` is supposedly 
associated primarily with generics is not compelling to me; it's currently used 
for protocol composition already, and there are generic features (constrained 
extensions) that don't use it.

(Consider this my weak -0.5 review against a proposal I helped to author.)

Austin

> 
> Jordan
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

> On Jun 24, 2016, at 6:04 PM, Jordan Rose  wrote:
> 
> 
>> On Jun 23, 2016, at 22:20, L. Mihalkovic  
>> wrote:
>> 
>> 
>> 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, although when I set out 
>>> earlier today to record my usual rebuttal I found that it really was mostly 
>>> a matter of taste. Yes, this looks weird to me:
>>> 
>>> let callback: (Data) -> NSCoding & NSCopying
>>> 
>>> but I’m sure the infix ‘->’ for functions looked weird to everyone the 
>>> first time they saw it as well, and it really is pretty clear in argument 
>>> position.
>>> 
>>> However, I did remember one issue, which was brought up on the previous 
>>> mega-thread: if we do want to generalize protocol values, we’re going to 
>>> want something that’s essentially “a type with a ‘where’ clauses in it”. I 
>>> really don’t want to force people to use a typealias to spell such a type, 
>>> but at the same time I want that where clause to be clearly attached to the 
>>> type. (As brought up before the return position of a function is currently 
>>> ambiguous with SE-0081.)
>>> 
>>> Despite the lightweightedness and the well-prepared proposal by Adrian and 
>>> Austin, the lack of bracketing <> () {} [] leads me to maintain my stance 
>>> against the proposed syntax.
>> 
>> This is another way to generalize P compositions that opens another way to 
>> specify WHERE
>> 
>> https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051
> 
> Thanks for bringing this up. I know one reason we’ve avoided syntax like this 
> in the past is the potential for static subscripts, but of course that’s just 
> one of many future concerns.
> 
> Jordan

Thank you for reading.

Originally i wanted to make "[" and "]" be CONSTRAINT_BEGIN and CONSTRAINT_END 
respectively to signify that what mattered was the overall structure and how it 
degenerated into this syntax when the composition is not applied to a concrete 
type (i.e. naked P), as well as show that this gave a formal definition to 
Any: a zero term composition that is not limited to a single concrete type, 
otherwise spelled "_ CONSTRAINT_BEGIN CONSTRAINT_END"

Anyhow, it was an interesting mental exercise.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Cantrell via swift-evolution]

Way back when, there was an unresolved discussion was about whether it’s a bug 
or a feature that $0 sometimes captures a single arg and sometimes captures all 
args as a tuple:

http://thread.gmane.org/gmane.comp.lang.swift.evolution/3915/
https://bugs.swift.org/browse/SR-586

I mention this because it would be a breaking change to make $0 consistently 
capture the first arg, and I wonder whether that should be in the Swift 3?

(If anybody wants to comment on the question, I recommend catching up on the 
discussion in the links above first.)

Cheers, P


> On Jun 22, 2016, at 8:07 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hi everyone,
> 
> Here is a partial list of the open topics that the core team would like to 
> get resolved in Swift 3.  The list is partial both because I’m way behind on 
> swift-evolution traffic, but also because new things may come up.  There are 
> also a number of accepted proposals that are not yet implemented.  Some 
> topics have proposals done, and therefore have an SE number, but the review 
> discussion hasn’t finalized.  Some of these topics have an “owner” that is 
> driving or planning to start a discussion on them them, which I’ve listed in 
> square brackets. 
> 
> If you’d like to discuss these topics in particular, please start a new 
> thread specific to them, or contribute to an already-existing thread 
> discussing it.  Several of these don’t have an owner yet, so if you’d like to 
> pick them up and run with them, that would be great.  Thanks!
> 
> -Chris
> 
> 
> Language:
> - SE-0091: Improving operator requirements in protocols [Core team discussed 
> this, will email about it shortly]
> - SE-0077: Improve operator declaration syntax [Core team discussed this, Joe 
> Groff will follow up on this soon]
> - SE-0095: Replace protocol syntax with P1 & P2 syntax
> - SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type
> - SE-0103: Invert @noescape
> - Remove T -> T? implicit promotion for operands to operators
> - Removing argument labels from the type system (so they are declaration-only 
> constructs)
> - Some reshuffling with requiring @objc/@nonobjc for things that 
> shouldn’t/can’t be expressed via the Objective-C runtime
> - Eliminating inference of associated type witnesses (as is mentioned in the 
> generics manifesto)
> - Should public classes be non-publicly-subclassable by default? [John McCall]
> - Revising access modifiers on extensions [Adrian Zubarev]
> 
> 
> Standard library:
> - SE-0101: Rename sizeof and related functions to comply with API Guidelines
> - Ongoing API naming adjustments for stdlib:
>- Closure arguments [Dave Abrahams]
>- Others are being discussed on swift-evolution.
> - Remove Boolean protocol.
> - SE-0104: Revise Integer protocols to match FP ones. [Max Moiseev]
> 
> SDK / Cocoa / ObjC interop:
> - [SE-0086] Finalize NS removal plan. [Tony Parker]
> - Importing “id” as Any [Joe Groff]
> - Revise NSError/Error model for better interoperability and usability. [Doug 
> Gregor]
> -  Bridge NSRange to “Range?”
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

Although i understand the intention, there are existing designs in other 
languages offering proven better alternatives. So i would not leave thinking 
that a compelling case for 'Never' has been made.

> On Jun 24, 2016, at 6:01 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0102-
> noreturn-bottom-type.md
> 
> I can think of at least one example of using Never.
> Suppose Stream protocol that returns a value at the end:
> 
> protocol Stream {
>associatedtype Element
>associatedtype Result
> 
>mutable func next() -> Either
> }
> 
> Result can be used for information why the stream has stopped.
> Calling next() after it returns Result is undefined behaviour.
> 
> You can easily see that Iterator is a special case of Stream
> with Result = ().
> 
> Algorithms on IteratorWithResult should not drop the result:
> 
> func forEach(stream: inout S,
>block: (S.Element) -> ())
>-> S.Result
>where S: Stream
> 
> We can split our Stream nicely:
> 
> func split(stream: inout S,
>  take: Int)
>  -> TakePrefixStream
>  where S: Stream
> 
> TakePrefixStream.Result is also a Stream, so to process two parts of 
> stream differently, we do:
> 
> split(s, take: 10).forEach(calledOnFirstTen).forEach(calledOnOthers)
> 
> In the same spirit, we can split a stream into 3 or N parts.
> Note that split itself does not take any elements from the Stream,
> everything is lazy.
> 
> You've already noticed where Never has its place.
> If a stream is infinite, we use Result = Never.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

> On Jun 23, 2016, at 22:20, L. Mihalkovic  wrote:
> 
> 
> 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, although when I set out 
>> earlier today to record my usual rebuttal I found that it really was mostly 
>> a matter of taste. Yes, this looks weird to me:
>> 
>> let callback: (Data) -> NSCoding & NSCopying
>> 
>> but I’m sure the infix ‘->’ for functions looked weird to everyone the first 
>> time they saw it as well, and it really is pretty clear in argument position.
>> 
>> However, I did remember one issue, which was brought up on the previous 
>> mega-thread: if we do want to generalize protocol values 
>> ,
>>  we’re going to want something that’s essentially “a type with a ‘where’ 
>> clauses in it”. I really don’t want to force people to use a typealias to 
>> spell such a type, but at the same time I want that where clause to be 
>> clearly attached to the type. (As brought up before the return position of a 
>> function is currently ambiguous with SE-0081 
>> .)
>> 
>> Despite the lightweightedness and the well-prepared proposal by Adrian and 
>> Austin, the lack of bracketing <> () {} [] leads me to maintain my stance 
>> against the proposed syntax.
> 
> This is another way to generalize P compositions that opens another way to 
> specify WHERE
> 
> https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051 
> 
Thanks for bringing this up. I know one reason we’ve avoided syntax like this 
in the past is the potential for static subscripts, but of course that’s just 
one of many future concerns.

Jordan___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Anton Zhilin via swift-evolution]

https://github.com/apple/swift-evolution/blob/master/proposals/0102-
noreturn-bottom-type.md

I can think of at least one example of using Never.
Suppose Stream protocol that returns a value at the end:

protocol Stream {
associatedtype Element
associatedtype Result

mutable func next() -> Either
}

Result can be used for information why the stream has stopped.
Calling next() after it returns Result is undefined behaviour.

You can easily see that Iterator is a special case of Stream
with Result = ().

Algorithms on IteratorWithResult should not drop the result:

func forEach(stream: inout S,
block: (S.Element) -> ())
-> S.Result
where S: Stream

We can split our Stream nicely:

func split(stream: inout S,
  take: Int)
  -> TakePrefixStream
  where S: Stream

TakePrefixStream.Result is also a Stream, so to process two parts of 
stream differently, we do:

split(s, take: 10).forEach(calledOnFirstTen).forEach(calledOnOthers)

In the same spirit, we can split a stream into 3 or N parts.
Note that split itself does not take any elements from the Stream,
everything is lazy.

You've already noticed where Never has its place.
If a stream is infinite, we use Result = Never.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

I find these 'stay-off-my-property' _ rather sub-par in a modern language 
(everything was different for c 40years ago). I find it rather sad to think 
that we r about to commit to using that pattern for another 30 years. If the 
demark between stdlib and compiler was cleaned up, it would even open the door 
to a clean way to make some embedded stdlib versions in the future
Regards
LM
(From mobile)

> On Jun 24, 2016, at 5:22 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I’m aware of that fact, but all types with underscore even in the stdlib 
> telling me to keep my hands of them, because something might happen to them.
> 
> As an example we have _Strideable protocol which is visible by its name, but 
> its declaration isn’t visible at all:
> 
> // FIXME(ABI)(compiler limitation): Remove `_Strideable`.
> // WORKAROUND rdar://25214598 - should be:
> // protocol Strideable : Comparable {...}
> 
> % for Self in ['_Strideable', 'Strideable']:
> From Stride.swift.gyb
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matt...@anandabits.com) 
> schrieb:
> 
>> The underscore is used in the same way it is used elsewhere in the standard 
>> library.  The protocols must be public because they need to be visible to 
>> user code in order for the design to work correctly.  However, they are 
>> considered implementation details that users really shouldn’t know about.  
>> This pattern is well established in the standard library.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

That said, how about this design:

public protocol _LiteralNilProtocol { … }
…

public enum Literal {
 
public typealias NilProtocol = …
…
}
extension Array: Literal.ArrayProtocol  


-- 
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:37:27, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

Really? I must have overlooked that some pitched that design.

Okay now that I think through this whole scenario, I like the underscore iff 
there is a good name that will be present in the final version.

When Swift 3 drops, I’ll write a proposal for nested protocols which will 
refine your design (the original author went missing after pitching this idea, 
and Joe Groff told me that this probably out of scope for Swift 3)!

Your current design might become this in Swift 3.X and all protocols marked 
with an underscore will disappear:

public /* closed */ enum Syntax {
  public protocol NilLiteral { ... }
  public protocol BooleanLiteral { ... }
  public protocol IntegerLiteral { ... }
  public protocol FloatLiteral { ... }
  public protocol UnicodeScalarLiteral { ... }
  public protocol ExtendedGraphemeClusterLiteral { ... }
  public protocol StringLiteralLiteral { ... }
  public protocol StringInterplolationLiteral { ... }
  public protocol ArrayrLiteral { ... }
  public protocol DictionaryLiteral { ... }
}


-- 
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:25:45, Matthew Johnson (matt...@anandabits.com) schrieb:

The design in this proposal comes from the standard library team.  The intent 
is for the use of underscore here to be consistent with other uses of 
underscore prefix in the standard library.  I’m not sure why you think this is 
different than the rest...


On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution 
 wrote:

I’m aware of that fact, but all types with underscore even in the stdlib 
telling me to keep my hands of them, because something might happen to them.

As an example we have _Strideable protocol which is visible by its name, but 
its declaration isn’t visible at all:
// FIXME(ABI)(compiler limitation): Remove `_Strideable`.
// WORKAROUND rdar://25214598 - should be:
// protocol Strideable : Comparable {...}

% for Self in ['_Strideable', 'Strideable']:
From Stride.swift.gyb




-- 
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matt...@anandabits.com) schrieb:

The underscore is used in the same way it is used elsewhere in the standard 
library.  The protocols must be public because they need to be visible to user 
code in order for the design to work correctly.  However, they are considered 
implementation details that users really shouldn’t know about.  This pattern is 
well established in the standard library.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

Really? I must have overlooked that some pitched that design.

Okay now that I think through this whole scenario, I like the underscore iff 
there is a good name that will be present in the final version.

When Swift 3 drops, I’ll write a proposal for nested protocols which will 
refine your design (the original author went missing after pitching this idea, 
and Joe Groff told me that this probably out of scope for Swift 3)!

Your current design might become this in Swift 3.X and all protocols marked 
with an underscore will disappear:

public /* closed */ enum Syntax {
  public protocol NilLiteral { ... }
  public protocol BooleanLiteral { ... }
  public protocol IntegerLiteral { ... }
  public protocol FloatLiteral { ... }
  public protocol UnicodeScalarLiteral { ... }
  public protocol ExtendedGraphemeClusterLiteral { ... }
  public protocol StringLiteralLiteral { ... }
  public protocol StringInterplolationLiteral { ... }
  public protocol ArrayrLiteral { ... }
  public protocol DictionaryLiteral { ... }
}


-- 
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:25:45, Matthew Johnson (matt...@anandabits.com) schrieb:

The design in this proposal comes from the standard library team.  The intent 
is for the use of underscore here to be consistent with other uses of 
underscore prefix in the standard library.  I’m not sure why you think this is 
different than the rest...


On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution 
 wrote:

I’m aware of that fact, but all types with underscore even in the stdlib 
telling me to keep my hands of them, because something might happen to them.

As an example we have _Strideable protocol which is visible by its name, but 
its declaration isn’t visible at all:
// FIXME(ABI)(compiler limitation): Remove `_Strideable`.
// WORKAROUND rdar://25214598 - should be:
// protocol Strideable : Comparable {...}

% for Self in ['_Strideable', 'Strideable']:
From Stride.swift.gyb




-- 
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matt...@anandabits.com) schrieb:

The underscore is used in the same way it is used elsewhere in the standard 
library.  The protocols must be public because they need to be visible to user 
code in order for the design to work correctly.  However, they are considered 
implementation details that users really shouldn’t know about.  This pattern is 
well established in the standard library.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Having reference semantics counterpart of value types in an easier way

[Amir Abbas Mousavian via swift-evolution]

Having reference semantics counterpart of value types in an easier way


Introduction

———

Now swift has its basic datatypes as value semantics. Arrays, Int.
Dictionaries, Sets and … are struct types without any kind of inheritance.

To compensate it, programmers usually use NS classes of these types. We are
about to introducing a new way to have reference types in a more swifty way
rather than using Foundation framework.

Swift 3 introduce omitting NS prefix from Foundation framework but leaves
NS prefix for some types with struct counterparts like Array, which may
leads to inconstancy for developers, and many datatypes remain classes (e.g
URL) which should be struct in swift paradigm while they remained classes


Motivation

———

Programmers usually have to memorize the counterpart of Swift datatypes in
Foundation easily.  Besides many datatypes remain classes (e.g URL) which
should be struct in swift paradigm while they remained classes



Proposed solution

———

We can match existing classes to their value-type counterpart like this:


class Array: NSArray as reftype of Array {

}


The compiler should check all Array struct functions are implemented in
this new class type otherwise throw an compile error. For de novo
declarations:


class ValType as reftype of ValType {

}


here, the only thing user has to is reimplement mutating functions here, or
use Bridgeable protocol. I've no idea here yet


To create a reference Array (former NSArray) programmer can simply do:


let NSArrayInstance: *Array[NSObject] = [];

or

let NSArrayInstance: reftype Array[NSObject] = [];


Alternative solution

———

Leave Foundation framework as it is by now.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brandon Knope via swift-evolution]

> On Jun 24, 2016, at 11:06 AM, Sean Heber via swift-evolution 
>  wrote:
> And these 2 made good use, IMO, of “if-where” but I think that’s no longer in 
> Swift 3? :/
> 
> 
> if let there = debugClickedSurfaceAt, here = mouseSurface where 
> Global.debugPathTest {
> }
> 
> if let here = mouseAt where Global.debugWalkNeighbors {
> }
> 

Just for completeness, these will now be:

if let there = debugClickedSurfaceAt, let here = mouseSurface, 
Global.debugPathTest {
}

if let here = mouseAt, Global.debugWalkNeighbors {
}

Not too sure if this is any clearer ¯\_(ツ)_/¯ 


> 
> l8r
> Sean
> 
> 
> 
> 
>> On Jun 24, 2016, at 8:24 AM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> Thank you for collecting and sharing these. 
>> 
>> I suspect both of us look at these and say "Ah yes, this supports exactly 
>> what I've been saying".
>> 
>> -- E
>> 
>>> On Jun 23, 2016, at 11:59 PM, William Shipley  wrote:
>>> 
>>> Here are some of my real-world examples:
>>> 
>>>for modelUUIDAndInterfaceElement in modelUUIDsToInterfaceElements 
>>> where !usedInterfaceElements.contains(modelUUIDAndInterfaceElement.1) {
>>> …
>>>}
>>> 
>>>for anchor in wall.anchors where boundsRect.contains(anchor.origin) {
>>> …
>>>}
>>> 
>>>for otherWall: Wall in self where otherWall != wall && 
>>> !removedWalls.contains(otherWall) {
>>> …
>>>}
>>> 
>>>for wall in self as Set {
>>>for otherWall in self as Set where otherWall != wall {
>>> …
>>>}
>>>}
>>> 
>>>for wall in self as Set where !checkedWalls.contains(wall) {
>>> …
>>>} 
>>> 
>>> (x2 on that one)
>>> 
>>>for otherPieceOfFurnitureNode in 
>>> localFurnitureModelUUIDsToInterfaceElements!.values where 
>>> otherPieceOfFurnitureNode !== pieceOfFurnitureNode {
>>> …
>>>}
>>> 
>>>for lineSegmentObject in wallRelatedLineSegments where 
>>> remainingLineSegments.contains(lineSegmentObject) {
>>> …
>>>}
>>> 
>>>for colinearLineSegmentObject in remainingLineSegments where 
>>> colinearLineSegmentObject.angle.isEssentially(infiniteLineAngle: 
>>> lineSegmentObject.angle) {
>>> …
>>>}
>>> 
>>> 
>>> I think this is basically as many as are found on all of github?
>>> 
>>> -W
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

The design in this proposal comes from the standard library team.  The intent 
is for the use of underscore here to be consistent with other uses of 
underscore prefix in the standard library.  I’m not sure why you think this is 
different than the rest...


> On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I’m aware of that fact, but all types with underscore even in the stdlib 
> telling me to keep my hands of them, because something might happen to them.
> 
> As an example we have _Strideable protocol which is visible by its name, but 
> its declaration isn’t visible at all:
> // FIXME(ABI)(compiler limitation): Remove `_Strideable`.
> // WORKAROUND rdar://25214598  - should be:
> // protocol Strideable : Comparable {...}
> 
> % for Self in ['_Strideable', 'Strideable']:
> From Stride.swift.gyb 
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matt...@anandabits.com 
> ) schrieb:
> 
>> The underscore is used in the same way it is used elsewhere in the standard 
>> library.  The protocols must be public because they need to be visible to 
>> user code in order for the design to work correctly.  However, they are 
>> considered implementation details that users really shouldn’t know about.  
>> This pattern is well established in the standard library.
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

I’m aware of that fact, but all types with underscore even in the stdlib 
telling me to keep my hands of them, because something might happen to them.

As an example we have _Strideable protocol which is visible by its name, but 
its declaration isn’t visible at all:

// FIXME(ABI)(compiler limitation): Remove `_Strideable`.
// WORKAROUND rdar://25214598 - should be:
// protocol Strideable : Comparable {...}

% for Self in ['_Strideable', 'Strideable']:
From Stride.swift.gyb



-- 
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matt...@anandabits.com) schrieb:

The underscore is used in the same way it is used elsewhere in the standard 
library.  The protocols must be public because they need to be visible to user 
code in order for the design to work correctly.  However, they are considered 
implementation details that users really shouldn’t know about.  This pattern is 
well established in the standard library.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] UnsafeRawPointer API

[Matthew Johnson via swift-evolution]

Andrew, thank you for working on this.  The latest draft is much improved!

I have a few questions.

Why do you require explicitly passing the type in these signatures?

func initialize(_: T.Type, with: T, count: Int = 1) -> 
UnsafeMutablePointer
func initialize(toContiguous: T.Type, atIndex: Int, with: T) -> 
UnsafeMutablePointer
func storeRaw(_: T.Type, with: T)
func storeRaw(toContiguous: T.Type, atIndex: Int, with: T)

There is probably a good reason, but it seems redundant at first glance and 
isn’t obvious from my reading of the proposal.  The alternatives would be 
something like this:

func initialize(with: T, count: Int = 1) -> UnsafeMutablePointer



The parameter order in this signature is the opposite of the order in 
UnsafeMutablePointer.  Is that intentional?  If so, what is the rationale?  You 
might want to elaborate this in the proposal.

public func + (lhs: Int, rhs: UnsafeRawPointer) -> UnsafeRawPointer



Shouldn’t the precondition be that memory for all elements is *uninitialized* / 
*deinitialized* in this example?

// - precondition: memory for all elements is initialized.
func freeCBuffer() {
  UnsafeRawPointer(ptrToA).deallocate(capacity: eltCount, of: A.self)
}




It looks like there is a type in this example:

var anyT = T(...)
takesTPtr()
takesVoidPtr()

Should the last line say ``?



Other than these few questions all I can say is that this looks great!  I 
believe it will add important clarity to code that works with unsafe pointers.

-Matthew

> On Jun 23, 2016, at 8:40 PM, Andrew Trick via swift-evolution 
>  wrote:
> 
> 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, and the 
> memory model has been simplified and clarified.
> 
> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md
> 
> If you have opinions or suggestions on API syntax, please make yourself 
> heard. You can jump straight to the naming discussion here:
> 
> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md#variations-under-consideration
> 
> Of particular interest may be the API names for:
> 
> - Memory allocation/deallocation: fairly fundamental to the language.
> 
> - Unsafe casting from raw pointers to typed pointers. This is going to impact 
> a lot of code that needs C interoperability.
> 
> Keep in mind that we will make additive API improvements later for 
> convenience. We want the fundamentals to be clear, explicit, and reasonably 
> safe.
> 
> -Andy
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[T.J. Usiyan via swift-evolution]

I think that we should change it to `if. Inline filtering is useful, even
if it isn't used much at present but the inconsistency doesn't help
adoption.

On Fri, Jun 24, 2016 at 11:06 AM, Sean Heber via swift-evolution <
swift-evolution@swift.org> wrote:

> I’ll share some of mine from a single game project. Note this hasn’t been
> converted to Swift 3 and this is not all of them - just a varied sampling:
>
>
> for location in random.sample(map, density: 0.007) where
> map.allowsGrassAt(location) && !map.hasGrassAt(location) {
> }
>
> for location in type.designatedLocations where location.z ==
> Global.cameraZ && !locations.contains(location) {
> }
>
> for location in region where location.z == mouseLocation.z {
> }
>
> for location in path where location.z == Global.cameraZ {
> }
>
> for below in location.below.cardinals where contains(below) &&
> hasSurfaceAt(below) {
> }
>
> for neighbor in location.cardinals where contains(neighbor) &&
> isRampAt(neighbor) && !isFloorAt(neighbor.above) {
> }
>
> for neighbor in cardinals where contains(neighbor) && !isSolidAt(neighbor)
> {
> }
>
> for console in consoles.reverse() where console.hitTest(vector) {
> }
>
>
>
> And these 2 made good use, IMO, of “if-where” but I think that’s no longer
> in Swift 3? :/
>
>
> if let there = debugClickedSurfaceAt, here = mouseSurface where
> Global.debugPathTest {
> }
>
> if let here = mouseAt where Global.debugWalkNeighbors {
> }
>
>
> l8r
> Sean
>
>
>
>
> > On Jun 24, 2016, at 8:24 AM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Thank you for collecting and sharing these.
> >
> > I suspect both of us look at these and say "Ah yes, this supports
> exactly what I've been saying".
> >
> > -- E
> >
> >> On Jun 23, 2016, at 11:59 PM, William Shipley  wrote:
> >>
> >> Here are some of my real-world examples:
> >>
> >> for modelUUIDAndInterfaceElement in
> modelUUIDsToInterfaceElements where
> !usedInterfaceElements.contains(modelUUIDAndInterfaceElement.1) {
> >> …
> >> }
> >>
> >> for anchor in wall.anchors where
> boundsRect.contains(anchor.origin) {
> >> …
> >> }
> >>
> >> for otherWall: Wall in self where otherWall != wall &&
> !removedWalls.contains(otherWall) {
> >> …
> >> }
> >>
> >> for wall in self as Set {
> >> for otherWall in self as Set where otherWall != wall {
> >> …
> >> }
> >> }
> >>
> >> for wall in self as Set where
> !checkedWalls.contains(wall) {
> >> …
> >> }
> >>
> >> (x2 on that one)
> >>
> >> for otherPieceOfFurnitureNode in
> localFurnitureModelUUIDsToInterfaceElements!.values where
> otherPieceOfFurnitureNode !== pieceOfFurnitureNode {
> >> …
> >> }
> >>
> >> for lineSegmentObject in wallRelatedLineSegments where
> remainingLineSegments.contains(lineSegmentObject) {
> >> …
> >> }
> >>
> >> for colinearLineSegmentObject in remainingLineSegments where
> colinearLineSegmentObject.angle.isEssentially(infiniteLineAngle:
> lineSegmentObject.angle) {
> >> …
> >> }
> >>
> >>
> >> I think this is basically as many as are found on all of github?
> >>
> >> -W
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Sean Heber via swift-evolution]

I’ve occasionally thought something like that would be handy, but usually I 
find a way to reorganize it so it’s not necessary and it works just as well. 
Hard to say, really. Adding power might be good, but adding too much power 
might easily cross my own threshold of “too complex”.

I do think that proper consideration should be given to moving “where”. For 
example, here are a few of mine re-ordered:


for location where location.z == Global.cameraZ in path {
}

for below where contains(below) && hasSurfaceAt(below) in 
location.below.cardinals {
}

for neighbor where contains(neighbor) && isRampAt(neighbor) && 
!isFloorAt(neighbor.above) in location.cardinals {
}


To me that’s just as good and perhaps even better since it groups the name of 
the thing with the rules for the thing.

l8r
Sean



> On Jun 24, 2016, at 10:10 AM, Charlie Monroe  
> wrote:
> 
> If the `where` keyword were to stay in the language, how would you feel about 
> extending it? One major argument is that it is not as powerful as guard or 
> if. How about something like this was allowed:
> 
> for text in self.texts where let data = text.data(usingEncoding: 
> NSASCIIEncoding) {
>   /// Do something with data or text
> }
> 
> 
>> On Jun 24, 2016, at 5:06 PM, Sean Heber via swift-evolution 
>>  wrote:
>> 
>> I’ll share some of mine from a single game project. Note this hasn’t been 
>> converted to Swift 3 and this is not all of them - just a varied sampling:
>> 
>> 
>> for location in random.sample(map, density: 0.007) where 
>> map.allowsGrassAt(location) && !map.hasGrassAt(location) {
>> }
>> 
>> for location in type.designatedLocations where location.z == Global.cameraZ 
>> && !locations.contains(location) {
>> }
>> 
>> for location in region where location.z == mouseLocation.z {
>> }
>> 
>> for location in path where location.z == Global.cameraZ {
>> }
>> 
>> for below in location.below.cardinals where contains(below) && 
>> hasSurfaceAt(below) {
>> }
>> 
>> for neighbor in location.cardinals where contains(neighbor) && 
>> isRampAt(neighbor) && !isFloorAt(neighbor.above) {
>> }
>> 
>> for neighbor in cardinals where contains(neighbor) && !isSolidAt(neighbor) {
>> }
>> 
>> for console in consoles.reverse() where console.hitTest(vector) {
>> }
>> 
>> 
>> 
>> And these 2 made good use, IMO, of “if-where” but I think that’s no longer 
>> in Swift 3? :/
>> 
>> 
>> if let there = debugClickedSurfaceAt, here = mouseSurface where 
>> Global.debugPathTest {
>> }
>> 
>> if let here = mouseAt where Global.debugWalkNeighbors {
>> }
>> 
>> 
>> l8r
>> Sean
>> 
>> 
>> 
>> 
>>> On Jun 24, 2016, at 8:24 AM, Erica Sadun via swift-evolution 
>>>  wrote:
>>> 
>>> Thank you for collecting and sharing these. 
>>> 
>>> I suspect both of us look at these and say "Ah yes, this supports exactly 
>>> what I've been saying".
>>> 
>>> -- E
>>> 
 On Jun 23, 2016, at 11:59 PM, William Shipley  wrote:
 
 Here are some of my real-world examples:
 
   for modelUUIDAndInterfaceElement in modelUUIDsToInterfaceElements 
 where !usedInterfaceElements.contains(modelUUIDAndInterfaceElement.1) {
 …
   }
 
   for anchor in wall.anchors where boundsRect.contains(anchor.origin) {
 …
   }
 
   for otherWall: Wall in self where otherWall != wall && 
 !removedWalls.contains(otherWall) {
 …
   }
 
   for wall in self as Set {
   for otherWall in self as Set where otherWall != wall {
 …
   }
   }
 
   for wall in self as Set where !checkedWalls.contains(wall) {
 …
   } 
 
 (x2 on that one)
 
   for otherPieceOfFurnitureNode in 
 localFurnitureModelUUIDsToInterfaceElements!.values where 
 otherPieceOfFurnitureNode !== pieceOfFurnitureNode {
 …
   }
 
   for lineSegmentObject in wallRelatedLineSegments where 
 remainingLineSegments.contains(lineSegmentObject) {
 …
   }
 
   for colinearLineSegmentObject in remainingLineSegments where 
 colinearLineSegmentObject.angle.isEssentially(infiniteLineAngle: 
 lineSegmentObject.angle) {
 …
   }
 
 
 I think this is basically as many as are found on all of github?
 
 -W
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

If the `where` keyword were to stay in the language, how would you feel about 
extending it? One major argument is that it is not as powerful as guard or if. 
How about something like this was allowed:

for text in self.texts where let data = text.data(usingEncoding: 
NSASCIIEncoding) {
/// Do something with data or text
}


> On Jun 24, 2016, at 5:06 PM, Sean Heber via swift-evolution 
>  wrote:
> 
> I’ll share some of mine from a single game project. Note this hasn’t been 
> converted to Swift 3 and this is not all of them - just a varied sampling:
> 
> 
> for location in random.sample(map, density: 0.007) where 
> map.allowsGrassAt(location) && !map.hasGrassAt(location) {
> }
> 
> for location in type.designatedLocations where location.z == Global.cameraZ 
> && !locations.contains(location) {
> }
> 
> for location in region where location.z == mouseLocation.z {
> }
> 
> for location in path where location.z == Global.cameraZ {
> }
> 
> for below in location.below.cardinals where contains(below) && 
> hasSurfaceAt(below) {
> }
> 
> for neighbor in location.cardinals where contains(neighbor) && 
> isRampAt(neighbor) && !isFloorAt(neighbor.above) {
> }
> 
> for neighbor in cardinals where contains(neighbor) && !isSolidAt(neighbor) {
> }
> 
> for console in consoles.reverse() where console.hitTest(vector) {
> }
> 
> 
> 
> And these 2 made good use, IMO, of “if-where” but I think that’s no longer in 
> Swift 3? :/
> 
> 
> if let there = debugClickedSurfaceAt, here = mouseSurface where 
> Global.debugPathTest {
> }
> 
> if let here = mouseAt where Global.debugWalkNeighbors {
> }
> 
> 
> l8r
> Sean
> 
> 
> 
> 
>> On Jun 24, 2016, at 8:24 AM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> Thank you for collecting and sharing these. 
>> 
>> I suspect both of us look at these and say "Ah yes, this supports exactly 
>> what I've been saying".
>> 
>> -- E
>> 
>>> On Jun 23, 2016, at 11:59 PM, William Shipley  wrote:
>>> 
>>> Here are some of my real-world examples:
>>> 
>>>for modelUUIDAndInterfaceElement in modelUUIDsToInterfaceElements 
>>> where !usedInterfaceElements.contains(modelUUIDAndInterfaceElement.1) {
>>> …
>>>}
>>> 
>>>for anchor in wall.anchors where boundsRect.contains(anchor.origin) {
>>> …
>>>}
>>> 
>>>for otherWall: Wall in self where otherWall != wall && 
>>> !removedWalls.contains(otherWall) {
>>> …
>>>}
>>> 
>>>for wall in self as Set {
>>>for otherWall in self as Set where otherWall != wall {
>>> …
>>>}
>>>}
>>> 
>>>for wall in self as Set where !checkedWalls.contains(wall) {
>>> …
>>>} 
>>> 
>>> (x2 on that one)
>>> 
>>>for otherPieceOfFurnitureNode in 
>>> localFurnitureModelUUIDsToInterfaceElements!.values where 
>>> otherPieceOfFurnitureNode !== pieceOfFurnitureNode {
>>> …
>>>}
>>> 
>>>for lineSegmentObject in wallRelatedLineSegments where 
>>> remainingLineSegments.contains(lineSegmentObject) {
>>> …
>>>}
>>> 
>>>for colinearLineSegmentObject in remainingLineSegments where 
>>> colinearLineSegmentObject.angle.isEssentially(infiniteLineAngle: 
>>> lineSegmentObject.angle) {
>>> …
>>>}
>>> 
>>> 
>>> I think this is basically as many as are found on all of github?
>>> 
>>> -W
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

Thanks for the feedback Adrian!

> On Jun 24, 2016, at 10:01 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I don’t like an underscore on public protocols. If we’re not forced to use 
> the proposed syntax at all it looks strange when you use a type with an 
> underscore (which to me represents something for private or internal usage).
> 
> 
The underscore is used in the same way it is used elsewhere in the standard 
library.  The protocols must be public because they need to be visible to user 
code in order for the design to work correctly.  However, they are considered 
implementation details that users really shouldn’t know about.  This pattern is 
well established in the standard library.

> In Swift we only can use literals for a single direction literal -> type, so 
> why don’t we just rename the protocols to look like:
> 
> 
This is a reasonable suggestion.  I’ll add it to the alternatives section.
> public protocol NilLiteralProtocol { ... }
> public protocol BooleanLiteralProtocol { ... }
> public protocol FloatLiteralProtocol { ... }
> public protocol IntegerLiteralProtocol { ... }
> public protocol UnicodeScalarLiteralProtocol { ... }
> public protocol ExtendedGraphemeClusterProtocol { ... }
> public protocol StringLiteralLiteralProtocol { ... }
> public protocol StringInterpolationLiteralProtocol { ... }
> public protocol ArrayLiteralProtocol { ... }
> public protocol DictionaryLiteralProtocol { ... }
> Here Protocol corresponds to the user that we’re about to access a specific 
> literal with our type which implements the protocol. (Just like 
> ErrorProtocol.)
> - extension Array : ArrayLiteralConvertible
> + extension Array : ArrayLiteralProtocol
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 24. Juni 2016 um 16:21:21, Vladimir.S via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> es are
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Sean Heber via swift-evolution]

I’ll share some of mine from a single game project. Note this hasn’t been 
converted to Swift 3 and this is not all of them - just a varied sampling:


for location in random.sample(map, density: 0.007) where 
map.allowsGrassAt(location) && !map.hasGrassAt(location) {
}

for location in type.designatedLocations where location.z == Global.cameraZ && 
!locations.contains(location) {
}

for location in region where location.z == mouseLocation.z {
}

for location in path where location.z == Global.cameraZ {
}

for below in location.below.cardinals where contains(below) && 
hasSurfaceAt(below) {
}

for neighbor in location.cardinals where contains(neighbor) && 
isRampAt(neighbor) && !isFloorAt(neighbor.above) {
}

for neighbor in cardinals where contains(neighbor) && !isSolidAt(neighbor) {
}

for console in consoles.reverse() where console.hitTest(vector) {
}



And these 2 made good use, IMO, of “if-where” but I think that’s no longer in 
Swift 3? :/


if let there = debugClickedSurfaceAt, here = mouseSurface where 
Global.debugPathTest {
}

if let here = mouseAt where Global.debugWalkNeighbors {
}


l8r
Sean




> On Jun 24, 2016, at 8:24 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Thank you for collecting and sharing these. 
> 
> I suspect both of us look at these and say "Ah yes, this supports exactly 
> what I've been saying".
> 
> -- E
> 
>> On Jun 23, 2016, at 11:59 PM, William Shipley  wrote:
>> 
>> Here are some of my real-world examples:
>> 
>> for modelUUIDAndInterfaceElement in modelUUIDsToInterfaceElements 
>> where !usedInterfaceElements.contains(modelUUIDAndInterfaceElement.1) {
>> …
>> }
>> 
>> for anchor in wall.anchors where boundsRect.contains(anchor.origin) {
>> …
>> }
>> 
>> for otherWall: Wall in self where otherWall != wall && 
>> !removedWalls.contains(otherWall) {
>> …
>> }
>> 
>> for wall in self as Set {
>> for otherWall in self as Set where otherWall != wall {
>> …
>> }
>> }
>> 
>> for wall in self as Set where !checkedWalls.contains(wall) {
>> …
>> } 
>> 
>> (x2 on that one)
>> 
>> for otherPieceOfFurnitureNode in 
>> localFurnitureModelUUIDsToInterfaceElements!.values where 
>> otherPieceOfFurnitureNode !== pieceOfFurnitureNode {
>> …
>> }
>> 
>> for lineSegmentObject in wallRelatedLineSegments where 
>> remainingLineSegments.contains(lineSegmentObject) {
>> …
>> }
>> 
>> for colinearLineSegmentObject in remainingLineSegments where 
>> colinearLineSegmentObject.angle.isEssentially(infiniteLineAngle: 
>> lineSegmentObject.angle) {
>> …
>> }
>> 
>> 
>> I think this is basically as many as are found on all of github?
>> 
>> -W
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Peternell via swift-evolution]

I'm not sure if this even requires a proposal. This just looks like an ordinary 
bug in the language implementation. But if this would become a formal proposal, 
I will support it.

-Michael

> Am 23.06.2016 um 21:53 schrieb Slava Pestov via swift-evolution 
> :
> 
> Consistent formal type for 'self' in class methods
> 
>   • Proposal: SE-
>   • Author: Slava Pestov
>   • Status: Awaiting review
>   • Review manager: TBD
> 
> Introduction
> 
> This proposal makes the self value behave consistently whether or not it is 
> used from a method with a Self return type.
> 
> Swift-evolution thread: Discussion thread topic for that proposal
> 
> 
> Motivation
> 
> Right now, we exhibit inconsistent behavior when self is used as an argument 
> to a generic function, violating the principle of least surprise.
> 
> Consider the following code:
> 
> class
>  Base {
>   
> @discardableResult
> 
>   
> func methodWithDynamicSelf() ->
>  Self {
> doSomething(
> self
> )
> 
> return self
> 
>   }
> 
>   
> func methodWithoutDynamicSelf
> () {
> doSomething(
> self
> )
>   }
> }
> 
> 
> class Derived :
>  Base {}
> 
> 
> func doSomething(_ t
> : T) {
>   
> print(T.self
> )
> }
> 
> Base()
> .
> methodWithDynamicSelf()
> Base()
> .
> methodWithoutDynamicSelf()
> 
> Derived()
> .
> methodWithDynamicSelf()
> Derived()
> .methodWithoutDynamicSelf()
> Currently, it prints the following output:
> 
> Base
> Base
> Derived
> Base
> 
> Note that there's no inconsistency when the method is called on the base 
> class. When called on the derived class however, we see that in a method with 
> a dynamic Self return type, the type of self is Derived, whereas in a method 
> with any other return type, the type of self is Base.
> 
> 
> Proposed solution
> 
> The proposal is to change the type of self to always be Self, which can be 
> thought of as a special generic type parameter bound to the dynamic type of 
> the instance.
> 
> With this proposal, the above code will instead produce the following:
> 
> Base
> Base
> Derived
> Derived
> 
> Here, the type of self would always be Derived when called on an instance of 
> the derived class.
> 
> Of course a more useful program could instead do something with the type 
> parameter T, such as constraining it to a protocol or a class with a required 
> initializer, and then using the type to construct a new instance of the class.
> 
> This also dovetails nicely with SE-0068.
> 
> Finally, it opens the door to generalizing dynamic Self, allowing it to 
> appear in covariant position within parameter types:
> 
> class
>  ArtClass {
>   
> func paint(withBrush: (Self) -> ()) { ...
>  }
> }
> 
> This would allow a class to conform to a protocol with a requirement written 
> like the following, something that is currently not possible at all:
> 
> protocol
>  OddProtocol {
>   
> func weaken((Self) ->
>  (X) -> Y) -> (X) -> Y
> }
> 
> 
> Detailed design
> 
> There's really not much more to say here. The code for typing self with a 
> dynamic Self is in place already, however enabling this change might expose 
> some new bugs we have not yet encountered, because currently, methods with 
> dynamic Self return type are relatively rare.
> 
> 
> Impact on existing code
> 
> This will have a small impact on existing code that uses a pattern similar to 
> the above.
> 
> 
> Alternatives considered
> 
> One alternative is to simply do nothing, but this makes the language less 
> consistent than it could be.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

I don’t like an underscore on public protocols. If we’re not forced to use the 
proposed syntax at all it looks strange when you use a type with an underscore 
(which to me represents something for private or internal usage).

In Swift we only can use literals for a single direction literal -> type, so 
why don’t we just rename the protocols to look like:

public protocol NilLiteralProtocol { ... }
public protocol BooleanLiteralProtocol { ... }
public protocol FloatLiteralProtocol { ... }
public protocol IntegerLiteralProtocol { ... }
public protocol UnicodeScalarLiteralProtocol { ... }
public protocol ExtendedGraphemeClusterProtocol { ... }
public protocol StringLiteralLiteralProtocol { ... }
public protocol StringInterpolationLiteralProtocol { ... }
public protocol ArrayLiteralProtocol { ... }
public protocol DictionaryLiteralProtocol { ... }
Here Protocol corresponds to the user that we’re about to access a specific 
literal with our type which implements the protocol. (Just like ErrorProtocol.)
- extension Array : ArrayLiteralConvertible
+ extension Array : ArrayLiteralProtocol


-- 
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 16:21:21, Vladimir.S via swift-evolution 
(swift-evolution@swift.org) schrieb:

es are
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

More smthg like this:

protocol PrecedGrpType{}
enum OperatorAssociativity { case left, right }
enum PrecedenceGroup {
casedefaultGroup(OperatorAssociativity)
indirect casestrongerThan(OperatorAssociativity,PrecedenceGroup)
indirect caseweakerThan(OperatorAssociativity,PrecedenceGroup)
}

let Additive: PrecedenceGroup = .defaultGroup(.left)
let Multiplicative: PrecedenceGroup = .strongerThan(.left, Additive)
let Exponentiative: PrecedenceGroup = .strongerThan(.left, Multiplicative)

standard Swift, which makes it easier to reflect when the api gets created in 40

Regards
LM
(From mobile)


>> On Jun 24, 2016, at 2:47 PM, Anton Zhilin via swift-evolution 
>>  wrote:
>> 
>> L. Mihalkovic via swift-evolution  writes:
>> 
 Could you please explain what you mean by "meta-circular syntax for
>> the 
 precedence group definitions"? An example?
>>> =define it using existing swift constructs rather than by extending
>> swift with new kwd looks like grp
>>> matches a struct.
>> 
>> I still don't fully understand without an example :(
>> If you mean something like this:
>> 
>> protocol PrecedenceGroup_Additive {
>>associatedtype StrongerThan_Comparative
>>associatedtype WeakerThan_Multiplicative
>> }
>> 
>> Then this is just ugly.
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

+1 from me. If I'll see `struct A : Syntax.NilLiteral {..}` I read this as 
"`A` could be represented in syntax as nil literal" or even "A could be a 
nil literal in syntax"


On 23.06.2016 18:31, Matthew Johnson via swift-evolution wrote:

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.
 It is also included below.

I will submit a PR in the next day or two after incorporating any feedback.

-Matthew


  Literal Syntax Protocols

  * Proposal: SE-
  * Author: Matthew Johnson 
  * Status: *Awaiting review*
  * Review manager: TBD


Introduction

This proposal renames the |*LiteralConvertible| protocols
to |Syntax.*Literal|.

Swift-evolution thread: Revisiting SE–0041 Names



Motivation

The standard library currently has protocols that use the
term |Convertible| in two different ways.
The |*LiteralConvertible| protocols use the meaning of converting /from/ a
literal. The |Custom(Debug)StringConvertible| protocols use the meaning of
converting /to/ a |String|. This causes confusion for developers attempting
to name their own protocols following the precedence established by the
standard library.

Further, the standard library team has observed:

|The "literal" protocols are not about conversion, they are about adopting a
certain syntax provided by the language. "Convertible" in the name is a red
herring: a type can't be convertible from an integer literal because there
is no "IntegerLiteral" entity in the type system. The literal *becomes*
typed as the corresponding literal type (e.g., Int or String), and as far
as the user at the call site is concerned, there is no visible conversion
(even if one is happening behind the scenes) |

An earlier proposal

 was
intended to address the first problem by introducing strong naming
conventions for three kinds of conversion protocols (/from/, /to/,
and /bidirectional/). The review highlighted the difficulity in
establishing conventions that everyone is happy with. This proposal takes a
different approach to solving the problem that originally inspired that
proposal while also solving the awkwardness of the current names described
by the standard library team.


Proposed solution

This proposal addresses both problems by introducing a |Syntax| “namespace”
and moving the |*LiteralConvertible| protocols into that “namespace” while
also renaming them. The proposal *does not* make any changes to the
requirements of the protocols.


Detailed design

All of the |*LiteralConvertible| protocols will receive
new |*Literal| names inside a |Syntax|namespace.

This namespace will initially be implemented using a case-less |enum|, but
this detail may change in the future if submodules or namespaces are added
to Swift. Swift does not currently allow protocols to be declared inside
the scope of a type. In order to work around this limitation the protocols
themselves will be declared using underscore-prefixed names internal to the
standard library. Typealiases inside the |Syntax| enum will declare the
names intended to be visible to user code.

This proposal does not change any requirements of these protocols. All
requirements of all |*LiteralConvertible| protocols will remain exactly the
same.

The following protocol declarations and names:

|public protocol NilLiteralConvertible { ... } public protocol
BooleanLiteralConvertible { ... } public protocol FloatLiteralConvertible {
... } public protocol IntegerLiteralConvertible { ... } public protocol
UnicodeScalarLiteralConvertible { ... } public protocol
ExtendedGraphemeClusterConvertible { ... } public protocol
StringLiteralLiteralConvertible { ... } public protocol
StringInterpolationLiteralConvertible { ... } public protocol
ArrayLiteralConvertible { ... } public protocol
DictionaryLiteralConvertible { ... }|

Are changed as follows:

|public protocol _NilLiteralSyntax { ... } public protocol
_BooleanLiteralSyntax { ... } public protocol _IntegerLiteralSyntax { ... }
public protocol _FloatLiteralSyntax { ... } public protocol
_UnicodeScalarLiteralSyntax { ... } public protocol
_ExtendedGraphemeClusterLiteralSyntax { ... } public protocol
_StringLiteralLiteralSyntax { ... } public protocol
_StringInterpolationLiteralSyntax { ... } public protocol
_ArrayLiteralSyntax { ... } public protocol _DictionaryLiteralSyntax { ...
} public /* closed */ enum Syntax { public typealias NilLiteral =
_NilLiteralSyntax public typealias BooleanLiteral = _BooleanLiteralSyntax
public typealias IntegerLiteral = _IntegerLiteralSyntax public typealias
FloatLiteral = _FloatLiteralSyntax public typealias UnicodeScalarLiteral =

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

[Vladimir.S via swift-evolution]

+1. This should be fixed.

On 23.06.2016 22:53, Slava Pestov via swift-evolution wrote:


  Consistent formal type for 'self' in class methods


* Proposal: SE-
  

* Author: Slava Pestov 
* Status: Awaiting review
* Review manager: TBD



Introduction


  This proposal makes the |self| value behave consistently whether or not
  it is used from a method with a |Self| return type.

  Swift-evolution thread: Discussion thread topic for that proposal
  



Motivation


  Right now, we exhibit inconsistent behavior when |self| is used as an
  argument to a generic function, violating the principle of least surprise.

  Consider the following code:

  class Base {
@discardableResult
func methodWithDynamicSelf() -> Self {
  doSomething(self)
  return self
}

func methodWithoutDynamicSelf() {
  doSomething(self)
}
  }

  class Derived : Base {}

  func doSomething(_ t: T) {
print(T.self)
  }

  Base().methodWithDynamicSelf()
  Base().methodWithoutDynamicSelf()

  Derived().methodWithDynamicSelf()
  Derived().methodWithoutDynamicSelf()

  Currently, it prints the following output:

  Base
  Base
  Derived
  Base

  Note that there's no inconsistency when the method is called on the base
  class. When called on the derived class however, we see that in a method
  with a dynamic |Self| return type, the type of |self| is |Derived|,
  whereas in a method with any other return type, the type of |self| is |Base|.



Proposed
solution


  The proposal is to change the type of |self| to always be |Self|, which
  can be thought of as a special generic type parameter bound to the
  dynamic type of the instance.

  With this proposal, the above code will instead produce the following:

  Base
  Base
  Derived
  Derived

  Here, the type of |self| would always be |Derived| when called on an
  instance of the derived class.

  Of course a more useful program could instead do something with the type
  parameter |T|, such as constraining it to a protocol or a class with a
  required initializer, and then using the type to construct a new instance
  of the class.

  This also dovetails nicely with SE-0068
  
.

  Finally, it opens the door to generalizing dynamic |Self|, allowing it to
  appear in covariant position within parameter types:

  class ArtClass {
func paint(withBrush: (Self) -> ()) { ... }
  }

  This would allow a class to conform to a protocol with a requirement
  written like the following, something that is currently not possible at all:

  protocol OddProtocol {
func weaken((Self) -> (X) -> Y) -> (X) -> Y
  }



Detailed
design


  There's really not much more to say here. The code for typing |self| with
  a dynamic |Self| is in place already, however enabling this change might
  expose some new bugs we have not yet encountered, because currently,
  methods with dynamic |Self| return type are relatively rare.



Impact
on existing code


  This will have a small impact on existing code that uses a pattern
  similar to the above.



Alternatives
considered


  One alternative is to simply do nothing, but this makes the language less
  consistent than it could be.



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Anton Zhilin via swift-evolution]

Vladimir.S via swift-evolution  writes:

> Do you mean *sorted*(by:) ? Or I'm missing something in naming rules?

IIRC, sort is mutating and sorted is nonmutating (copying) version.
Also, I forgot `initial` parameter in `reduce`.

> > Data flow is an area where code becomes the less understandable when
> > more visual clutter is added. In my opinion,
> >
> > array.filter(isEven).map(square).reduce(sum)
> >
> > reads better than
> >
> > array.filter(suchThatTrue: isEven).map(applyingTransformation:
> > square).reduce(accumulatingResultBy: sum)
> >
> > What do you think?
> 
> +100. I even want to brought the term-of-art argument here. IMO These 
> functions are expected to be called without any parameter names.

That would probably be a good scenario, but core team needs to release 
their grip on strictly following new naming conventions.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

On 24.06.2016 0:55, Anton Zhilin via swift-evolution wrote:

Dave Abrahams via swift-evolution  writes:


A couple of weeks ago we started to notice that we had some poorly-

named

closure parameters and argument labels in the standard library, so we
did a complete audit of the standard library's APIs and came up with a
preliminary proposal for changes, which we applied in a branch and you
can review in https://github.com/apple/swift/pull/2981.  Let's please
carry on further discussion here rather than in the pull request,

though.

I don't like that more clutter is added to the call site. We can surely
find shorter and more descriptive names. Remember that most people
already know what filter, map and reduce means, we don't need to explain
them.

My suggestions:

filter(where:)
map(over:)
reduce(applying:)
sort(by:)


Do you mean *sorted*(by:) ? Or I'm missing something in naming rules?


forEach(do:)

Remember that these functions came from functional languages, where
function names tend to be brief, and it is considered one of their
advantages.


+1



Data flow is an area where code becomes the less understandable when
more visual clutter is added. In my opinion,

array.filter(isEven).map(square).reduce(sum)

reads better than

array.filter(suchThatTrue: isEven).map(applyingTransformation:
square).reduce(accumulatingResultBy: sum)

What do you think?


+100. I even want to brought the term-of-art argument here. IMO These 
functions are expected to be called without any parameter names.


From other point, often these functions will be called with closures(i.e. 
without parameter names at all):


array.filter {$0 % 2 == 0} .map {$0*$0} .reduce(0) {$0+$1}



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Shorthand unwrap proposal

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jun 24, 2016, at 2:50 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> Yes, this is a bit different. There was a discussion about a month ago 
> (http://thread.gmane.org/gmane.comp.lang.swift.evolution/17142) which had a 
> few good ideas how to deal with the following pattern:
> 
> if let x = x { // do something with x }
> guard let x = x { return }
> 

For my own education i built

if let! x {
// x is shadowed
}


> which is shadowing the original optional value. The suggestion was:
> 
> if let x! { // within this block, x is no longer optional }
> 
> guard let x! { return }
> // Now x is no longer an optional.
> 
> Generally, it re-used the same variable name to safe-unwrap the optional. In 
> your particular example:
> 
> let i: Int? = nil
> if let i! {
>   let y = i.toIntMax()
>   /// ...
> }
> 
> I am aware of the .map (or flatMap) on the optional, however, the guard 
> statement in particular seems like an improvement.
> 
> There are many language constructs in Swift that can be expressed using other 
> constructs - you can go all the way down and say that you really don't need 
> anything other than if and goto.
> 
> The question is whether such a syntax sugar is something that would be help 
> one write safer code and if it's something people would use.
> 
> 
>> On Jun 23, 2016, at 9:32 PM, David Sweeris  wrote:
>> 
>> 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:
>>> 
>>> 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 - in that sense something like 
>>> doSomething(?: myOptional)(with: myOptional) makes more sense, declaring 
>>> explicitely what optionals does the execution depend on.
>>> - nevertheless, in the interest of clarity and readability of the code, I'm 
>>> still in favor of the original proposal, which requires you to either use 
>>> if or guard.
>>> 
 On Jun 23, 2016, at 8:57 PM, Tim Vermeulen  wrote:
 
 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 23, 2016, at 8:52 PM, Tim Vermeulenwrote:
>> 
>> 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 looks good to me, though if I were a newcomer to the 
>>> language, it would be really cryptic.
>>> 
>>> In case the function returned any value, it could become an optional, 
>>> just like with try?...
>>> 
>>> I still, however, prefer the original proposal of if let myOptional! { 
>>> doSomething(myOptional) }...
>>> 
 
 which would be equivalent to
 
 if let myValue = myOptional {
 doSomething(with: myValue)
 }
 
 But it’s been discussed here before, and I don’t think people were 
 very enthusiastic about it.
 
> 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"
> 
> let myReallyLongOptionalName: String? = "Hey"
> 
> myReallyLongOptionalName.unwrap {
> doSomethingWith($0)
> }
> 
> The block would only be fired if myReallyLongOptionalName has a value.
> 
> 
> ___
> 
> 
> James⎥Head of Trolls
> 
> 
> ja...@supmenow.com(mailto:ja...@supmenow.com)⎥supmenow.com(http://supmenow.com)
> 
> 
> Sup
> 
> 
> Runway East
> 
> 
> 10 Finsbury Square
> 
> 
> 

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

[Vladimir.S via swift-evolution]

On 24.06.2016 0:57, João Pinheiro via swift-evolution wrote:

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 proposed prohibiting them and
was convinced into thinking that ignoring them would suffice. Upon further
reading of the unicode normalisation and security documents, I agree that
prohibiting them outside of the situations described in UAX #31 is the best
and safest choice.


I do believe the *safest* variant should be chosen as, actually, do we see 
lot of sources with unicode identifiers? I believe very small percent in 
real code. IMO At first we should protect Swift from problems with unicode 
identifiers, and only after this support as much unicode as we can.
(Personally I really don't understand why we need anything than ASCII codes 
for identifiers. This could solve all the problems with invisible 
space/left-to-right-flags/complicated rules/graphemes etc. But someone 
needs to be able to put dog emoji as identifiers.. well.. OK)




Sincerely,
João Pinheiro



On 23 Jun 2016, at 21:45, Xiaodi Wu via swift-evolution
> wrote:

Let me correct myself: what I think Josh's example is should be corrected
whether we prohibit or ignore. However, since no one can see the
invisible characters he used, I can't say for sure.

If he found a clever way to reorder or change spacing between letters
(e.g. superimpose two characters so that "var11" looks like "var1"), then
the problem can only be fixed by prohibition.
On Thu, Jun 23, 2016 at 15:36 James Hillhouse > wrote:

Thanks Xiaodi. That’s a relief to know.



On Jun 23, 2016, at 3:32 PM, Xiaodi Wu > wrote:

FWIW, Josh's example would be fixed whether we prohibit or ignore
invisible characters, but there are other potential strings for
which prohibition would be more secure.

On Thu, Jun 23, 2016 at 15:27 James Hillhouse
> wrote:

+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, at 15:13, Xiaodi Wu via swift-evolution
>
wrote:


On Thu, Jun 23, 2016 at 2:54 PM, João Pinheiro
> 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 #31: overtly disallow the glyphs in Table 4 (instead of ignoring 
them) except in the specific scenarios for ZWJ and ZWNJ identified in UAX #31, 
then afterwards internally represent the identifier as its NFC-normalized string.

Explicitly disallowing them was my initial idea, but I
think it would end up being a confusing error for users to
encounter. Ignoring the invisible characters and leaving
it up to a linter to remove them is less likely to cause
confusion for users.

I'll be sure to describe the alternative of explicitly
prohibiting them in the proposal though.


I would strongly urge you to propose explicitly prohibiting
them just as UAX #31 recommends. Their reasoning is that these
characters, which include those that reverse text direction or
control joining, can cause one identifier to be maliciously
changed to look like another. If you ignore these characters
instead of prohibiting them, an identifier that visually
appears as one string could in fact be a different one to the
compiler.

Moreover, a compiler error can be made helpful by saying that
the offending character is potentially invisible and it can
come with a fix-it to remove the offending character. I don't
think that would confuse the user at all. It would be more
confusing if invisible characters that caused one thing to
look identical to another were silently permitted.


Sincerely,
João Pinheiro


___
swift-evolution mailing list
swift-evolution@swift.org 

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

[Erica Sadun via swift-evolution]

Thank you for collecting and sharing these. 

I suspect both of us look at these and say "Ah yes, this supports exactly what 
I've been saying".

-- E

> On Jun 23, 2016, at 11:59 PM, William Shipley  wrote:
> 
> Here are some of my real-world examples:
> 
> for modelUUIDAndInterfaceElement in modelUUIDsToInterfaceElements 
> where !usedInterfaceElements.contains(modelUUIDAndInterfaceElement.1) {
> …
> }
> 
> for anchor in wall.anchors where boundsRect.contains(anchor.origin) {
> …
> }
> 
> for otherWall: Wall in self where otherWall != wall && 
> !removedWalls.contains(otherWall) {
> …
> }
> 
> for wall in self as Set {
> for otherWall in self as Set where otherWall != wall {
> …
> }
> }
> 
> for wall in self as Set where !checkedWalls.contains(wall) {
> …
> } 
> 
> (x2 on that one)
> 
> for otherPieceOfFurnitureNode in 
> localFurnitureModelUUIDsToInterfaceElements!.values where 
> otherPieceOfFurnitureNode !== pieceOfFurnitureNode {
> …
> }
> 
> for lineSegmentObject in wallRelatedLineSegments where 
> remainingLineSegments.contains(lineSegmentObject) {
> …
> }
> 
> for colinearLineSegmentObject in remainingLineSegments where 
> colinearLineSegmentObject.angle.isEssentially(infiniteLineAngle: 
> lineSegmentObject.angle) {
> …
> }
> 
> 
> I think this is basically as many as are found on all of github?
> 
> -W

___
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

[Anton Zhilin via swift-evolution]

L. Mihalkovic via swift-evolution  writes:

> > Could you please explain what you mean by "meta-circular syntax for 
the 
> > precedence group definitions"? An example?
> =define it using existing swift constructs rather than by extending 
swift with new kwd looks like grp
> matches a struct. 

I still don't fully understand without an example :(
If you mean something like this:

protocol PrecedenceGroup_Additive {
associatedtype StrongerThan_Comparative
associatedtype WeakerThan_Multiplicative
}

Then this is just ugly.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[plx via swift-evolution]

-1 for the reasons already brought up. 

I would also point out that half the biasing argument is extremely 
questionable: yes, for-in-where is “biased” in favor of “visit-if” and not 
"visit-unless”, but this form of “bias” is inevitable unless you start 
multiplying keywords (to have one for each “polarity”).

Note that, e.g., `guard` is also biased in a particular direction — we have 
`guard $conditionThatMustBeTrue` but not `unless 
$conditionThatShouldNotBeFalse` — and although this choice *does* make sense 
(due to let-binding being a success-case), it *is* otherwise backwards from 
traditional guard clauses (which were usually `if $exitCondition { $exit }`, 
which is the opposite polarity from how `guard` works).

So unless you want to have 2 of every control-flow keyword, whenever you have 
just one of each you just have to learn the “polarity" of each…this seems 
inevitable. Also note that even if you *did* go for 2-of-each, picking names 
that are sufficiently self-evident is harder than it looks, so in practice 
you’d almost certainly still have to wind up learning at least one of them, if 
not both.

Additionally, I would point `for-in-where` has some unique aspects that would 
complicate taking the “remove today to improve tomorrow” approach (as has been 
done with some other features like splatting).

Specifically, using for-in-where is a stylistic decision, and although 
translating its uses *to* `guard-continue` form can be done mechanically, 
translating `guard-continue` *back* to the (successor of) `for-in-where` in a 
stylistically-appropriate way seems much harder to mechanize…so if it was 
dropped for later, improved reinstatement, the temporary dropping might result 
in losing a lot of the original human stylistic choice, which IMHO is useful 
evidence of the original human intent.

> On Jun 22, 2016, at 11:12 PM, Chris Lattner via swift-evolution 
>  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:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[plx via swift-evolution]

+1; I *really* appreciate taking a proactive approach to eliminating future 
sources of bizarre “gotcha” moments!

> 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 
> Status: Awaiting review
> Review manager: TBD
> 
>  
> Introduction
> 
> This proposal makes the self value behave consistently whether or not it is 
> used from a method with a Self return type.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> Right now, we exhibit inconsistent behavior when self is used as an argument 
> to a generic function, violating the principle of least surprise.
> 
> Consider the following code:
> 
> class Base {
>   @discardableResult
>   func methodWithDynamicSelf() -> Self {
> doSomething(self)
> return self
>   }
> 
>   func methodWithoutDynamicSelf() {
> doSomething(self)
>   }
> }
> 
> class Derived : Base {}
> 
> func doSomething(_ t: T) {
>   print(T.self)
> }
> 
> Base().methodWithDynamicSelf()
> Base().methodWithoutDynamicSelf()
> 
> Derived().methodWithDynamicSelf()
> Derived().methodWithoutDynamicSelf()
> Currently, it prints the following output:
> 
> Base
> Base
> Derived
> Base
> Note that there's no inconsistency when the method is called on the base 
> class. When called on the derived class however, we see that in a method with 
> a dynamic Self return type, the type of self is Derived, whereas in a method 
> with any other return type, the type of self is Base.
> 
> 
>  
> Proposed
>  solution
> 
> The proposal is to change the type of self to always be Self, which can be 
> thought of as a special generic type parameter bound to the dynamic type of 
> the instance.
> 
> With this proposal, the above code will instead produce the following:
> 
> Base
> Base
> Derived
> Derived
> Here, the type of self would always be Derived when called on an instance of 
> the derived class.
> 
> Of course a more useful program could instead do something with the type 
> parameter T, such as constraining it to a protocol or a class with a required 
> initializer, and then using the type to construct a new instance of the class.
> 
> This also dovetails nicely with SE-0068 
> .
> 
> Finally, it opens the door to generalizing dynamic Self, allowing it to 
> appear in covariant position within parameter types:
> 
> class ArtClass {
>   func paint(withBrush: (Self) -> ()) { ... }
> }
> This would allow a class to conform to a protocol with a requirement written 
> like the following, something that is currently not possible at all:
> 
> protocol OddProtocol {
>   func weaken((Self) -> (X) -> Y) -> (X) -> Y
> }
> 
>  
> Detailed
>  design
> 
> There's really not much more to say here. The code for typing self with a 
> dynamic Self is in place already, however enabling this change might expose 
> some new bugs we have not yet encountered, because currently, methods with 
> dynamic Self return type are relatively rare.
> 
> 
>  
> Impact
>  on existing code
> 
> This will have a small impact on existing code that uses a pattern similar to 
> the above.
> 
> 
>  
> Alternatives
>  considered
> 
> One alternative is to simply do nothing, but this makes the language less 
> consistent than it could be.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

> On Jun 24, 2016, at 11:25 AM, Patrick Smith via swift-evolution 
>  wrote:
> 
> I’ve never quite understood why people are so strict about keeping to this?

especially considering how many who do have never seen a vt100 terminal

> 
>> On 24 Jun 2016, at 4:04 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Not a practitioner of 80-character line limits, I take it?
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[William Shipley via swift-evolution]

Here are some of my real-world examples:

for modelUUIDAndInterfaceElement in modelUUIDsToInterfaceElements where 
!usedInterfaceElements.contains(modelUUIDAndInterfaceElement.1) {
…
}

for anchor in wall.anchors where boundsRect.contains(anchor.origin) {
…
}

for otherWall: Wall in self where otherWall != wall && 
!removedWalls.contains(otherWall) {
…
}

for wall in self as Set {
for otherWall in self as Set where otherWall != wall {
…
}
}

for wall in self as Set where !checkedWalls.contains(wall) {
…
} 

(x2 on that one)

for otherPieceOfFurnitureNode in 
localFurnitureModelUUIDsToInterfaceElements!.values where 
otherPieceOfFurnitureNode !== pieceOfFurnitureNode {
…
}

for lineSegmentObject in wallRelatedLineSegments where 
remainingLineSegments.contains(lineSegmentObject) {
…
}

for colinearLineSegmentObject in remainingLineSegments where 
colinearLineSegmentObject.angle.isEssentially(infiniteLineAngle: 
lineSegmentObject.angle) {
…
}


I think this is basically as many as are found on all of github?

-W___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution