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

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

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

> 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

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

> 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

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

> 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

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

> 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

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

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

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

> 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

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

> 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

Re: [swift-evolution] Shorthand unwrap proposal

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

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

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

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

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

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

> 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

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

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

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

+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

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

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

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

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

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

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,

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

> 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

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

> 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

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

> 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

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

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

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

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,

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

> 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

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

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

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

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

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

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 { … } >

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

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,

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

> 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

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

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

[swift-evolution] Collection index complexity and data structures

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

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

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

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

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,

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

> 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

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

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

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

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

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

> 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

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

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

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

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,

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

> 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

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

> 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

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

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

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

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

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

> 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

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

> 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

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

> 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

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

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

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

> 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

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

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

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

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

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

-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

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

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

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

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

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

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 :

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

> 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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

More smthg like this: protocol PrecedGrpType{} enum OperatorAssociativity { case left, right } enum PrecedenceGroup { casedefaultGroup(OperatorAssociativity) indirect casestrongerThan(OperatorAssociativity,PrecedenceGroup) indirect

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

+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

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

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

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

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

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

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

Re: [swift-evolution] Shorthand unwrap proposal

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

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

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

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

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

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

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 >

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

-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

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

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

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

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

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

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) { … }