Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

+1, as long as the weird dynamic @objc method lookup behavior on AnyObject isn't also carried over to Any as part of this proposal. This behavior is a source of frustration for me as it reduces how much I can reason about code i work with when it creeps in unknowingly, and I don't even like

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

> On Jul 2, 2016, at 2:39 PM, Riley Testut via swift-evolution > wrote: > >> When naming, we need to learn to stop treating the comfortable ring of >> familiar word patterns as an arbiter of success. > > I’m not sure I agree with this statement. I would argue we

Re: [swift-evolution] Random ideas: goto, loop, multiple dispatch, explicit aliasing

> On Jul 2, 2016, at 6:27 PM, Daryle Walker via swift-evolution > wrote: > > I would also propose a “goto LABEL case EXPRESSION,” where the LABEL marks a > “switch” statement that surrounds the goto statement and reevaluates the > switch with the new value. This

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0107: UnsafeRawPointer API

> * What is your evaluation of the proposal? I think this is basically a good design, but I have lots and lots of comments. * * * I have a pile of naming quibbles; rather than describe them all in prose (which turned into a mess), I've annotated parts of the "Full UnsafeRawPointer API"

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

on Sat Jul 02 2016, Riley Testut wrote: >> When naming, we need to learn to stop treating the comfortable ring of >> familiar word patterns as an arbiter of success. > > I’m not sure I agree with this statement. I would argue we should most > certainly aim to keep a

Re: [swift-evolution] Random ideas: goto, loop, multiple dispatch, explicit aliasing

Swift already has a very useful goto operator that avoids the usual problems associated with arbitrary control flow. With labels and continue/break you can implement very complex control flow schemas, but still maintain structured code. I have used it at multiple occasions and this is something

Re: [swift-evolution] Fixed-sized arrays

> On Jun 26, 2016, at 2:20 AM, Félix Cloutier wrote: > > There have been proposals about that, revolving around creating a new tuple > syntax for fixed-size arrays, like (Int x 5), and adding a subscript to them. > IIRC, the sentiment was largely positive but people couldn't

[swift-evolution] Random ideas: goto, loop, multiple dispatch, explicit aliasing

Rust and Ada (and probably others) have a iteration statement that specifically goes on forever, instead of using a convention of a “while”/“repeat-until”/“for" with a never-exiting test. It’s called “loop.” Would that be a good idea to add instead of continuing to use convention? (I don’t

Re: [swift-evolution] [Discussion] Static curried versions for variables and constants.

Great! I was trying to find it in a history, but was not able to do so. Thanks for suggestion regarding lens keyword. > On Jul 2, 2016, at 3:10 PM, Brent Royal-Gordon wrote: > >> On Jul 2, 2016, at 12:14 PM, Nikita Leonov via swift-evolution >>

Re: [swift-evolution] [Discussion] Static curried versions for variables and constants.

> On Jul 2, 2016, at 12:14 PM, Nikita Leonov via swift-evolution > wrote: > > I was trying to find what cause to not define static curried functions for > variables and constants and was not able to find a good reason. In brief: This has been deferred until after

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

On painting the relative-precedence bikeshed, I would lean slightly toward “before” and “after”. They are short, single words with unambiguous meaning. Moreover, the actual point of interest is “Which operators will be evaluated before which other ones?” Plus the word “precedence” itself

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

> When naming, we need to learn to stop treating the comfortable ring of > familiar word patterns as an arbiter of success. I’m not sure I agree with this statement. I would argue we should most certainly aim to keep a consistent feel across our naming conventions, and furthermore, I think

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

on Sat Jul 02 2016, Riley Testut wrote: > (My bad, accidentally hit send too early). > > That, or we could keep either the Convert or Express forms with > "IntegerLiteralConverting" or "IntegerLiteralExpressing". And if we > decide "express" really is the best word to describe what happens, I

[swift-evolution] [Discussion] Static curried versions for variables and constants.

Currently Swift provides a static curried function for every instance function defined. It pretty often allows to avoid closures and be explicit about functions used. For example: //flip — flipping an order of arguments for curried functions. var foo = [[0, 1], [1, 2], [2, 3], [3,

Re: [swift-evolution] [Proposal] Sealed classes by default

Regards LM (From mobile) On Jun 30, 2016, at 9:12 AM, John McCall wrote: >> On Jun 29, 2016, at 10:27 PM, L. Mihalkovic >> wrote: >> >> On Jun 29, 2016, at 9:54 PM, John McCall via swift-evolution >> wrote: >>

Re: [swift-evolution] [Pitch] Self.withoutSpecialization

I periodically kill all hope that we might get higher-kinded-types, just to remain sane. It's interesting that you would make them sound like a possibility though, since Mr Widmann said something about you declaring them intractable for some reason or another. Well, this attempt to get them by

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

Dave Abrahams via swift-evolution writes: > > But as some of them noted in the discussion, low-level protocols that > > interact with language syntax can focus on syntax entirely. I've not > > seen this point supported by other team members, though. > > > > Personally, I

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

> On Jul 2, 2016, at 1:20 AM, Goffredo Marocchi wrote: > > Hey Chris, > > Do you have plans to allow people to update Swift outside Xcode 8 point > updates and still be able to submit to the App Store and benefit from the > IDE's features? This could allow bug fixes to be

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0115: Rename Literal Syntax Protocols

Lets go back to the roots and create swifty-sembler. :) --  Adrian Zubarev Sent with Airmail Am 2. Juli 2016 um 18:35:15, Chris Lattner via swift-evolution (swift-evolution@swift.org) schrieb: +1 for removing literals, that would definitely solve this naming problem ;-)

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0115: Rename Literal Syntax Protocols

> On Jul 1, 2016, at 10:28 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md > > Frankly, every name mentioned in that proposal basically sucks, including

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

Dave Abrahams via swift-evolution writes: > on Sat Jul 02 2016, Anton Zhilin swift.org> wrote: > > > -1 from me. I suggest to wait until we get generic protocols > > in Swift 4, then we can use the following: > > > > protocol From { > > init(_ from: T) > > } > > > >

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

To be honest, that’s why I suggested the idea of Literal.IntegerProtocol with the Protocol suffix. If I’d read something like this extension Array : Literal.ArrayProtocol I won’t be confused what that protocol will do, because it doesn’t tell me the full behavior from its name. ErrorProtocol

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

(My bad, accidentally hit send too early). That, or we could keep either the Convert or Express forms with "IntegerLiteralConverting" or "IntegerLiteralExpressing". And if we decide "express" really is the best word to describe what happens, I personally prefer "IntegerLiteralExpressing" to

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

on Sat Jul 02 2016, Anton Zhilin wrote: > Matthew Johnson via swift-evolution writes: > >> >>> protocol From { >> >>> init(_ from: T) >> >>> } >> >> >> > With From definition given above, I would define > IntLiteralConvertible === >> > From,

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

I kinda agree that these names still aren't the best. FWIW, I much preferred the originals, even if they could be misleading. What if we changed the names to be verbs instead of adjectives? Something like "IntegerLiteralTransforming"? > On Jul 2, 2016, at 10:35 AM, Dave Abrahams via

Re: [swift-evolution] [Pitch] Self.withoutSpecialization

on Fri Jul 01 2016, "T.J. Usiyan via swift-evolution" wrote: > Bump > > On Fri, Jul 1, 2016 at 11:56 AM, T.J. Usiyan > wrote: > >> >> >> ## The Issue >> Given >> ``` swift >> public protocol Zipper1D : CustomStringConvertible { >>

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

on Sat Jul 02 2016, Anton Zhilin wrote: > -1 from me. I suggest to wait until we get generic protocols > in Swift 4, then we can use the following: > > protocol From { > init(_ from: T) > } > > And deprecate all the weird Convertibles. Even if we could do that,

Re: [swift-evolution] [Proposal] Sealed classes by default

+1 to sealed +1 to sealed-as-default. I prefer the need to explicitly share details that I would like to share. Separately, I do think that we need to improve the tools for auditing and organizing APIs. On Sat, Jul 2, 2016 at 8:35 AM, L. Mihalkovic via swift-evolution <

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

Matthew Johnson via swift-evolution writes: > >>> protocol From { > >>> init(_ from: T) > >>> } > >> > > With From definition given above, I would define IntLiteralConvertible === > > From, BoolLiteralConvertible === From, etc. That means, if you > > conform to From

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

Sent from my iPad On Jul 2, 2016, at 9:10 AM, Anton Zhilin via swift-evolution wrote: >>> Anton Zhilin via swift-evolution writes: >>> -1 from me. I suggest to wait until we get generic protocols >>> in Swift 4, then we can use the following:

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

On Jul 1, 2016, at 9:18 PM, Patrick Pijnappel wrote: >> > We might even be able to take the existing string-to-integer >> > logic, which I believe is duplicated for each type through GYB, and >> > share it in an extension so no Integer needs to write its own >> >

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

> >Anton Zhilin via swift-evolution writes: > > -1 from me. I suggest to wait until we get generic protocols > > in Swift 4, then we can use the following: > > > > protocol From { > >init(_ from: T) > > } > > I'm not sure this feature would be relevant in the case of

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

It does look like a huge benefit for many many current swift users. Thanks to the whole team trying to make this happen in Swift 3. On Fri, Jul 1, 2016 at 10:21 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jul 1, 2016, at 9:11 PM, David Waite via

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

Matthew Johnson via swift-evolution writes: > Sent from my iPad > > > On Jul 2, 2016, at 6:11 AM, Anton Zhilin via swift-evolution swift.org> wrote: > > > > -1 from me. I suggest to wait until we get generic protocols > > in Swift 4, then we can use the following: > > >

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

Sent from my iPad > On Jul 2, 2016, at 6:11 AM, Anton Zhilin via swift-evolution > wrote: > > -1 from me. I suggest to wait until we get generic protocols > in Swift 4, then we can use the following: > > protocol From { >init(_ from: T) > } This is extremely

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

Sent from my iPad > On Jul 1, 2016, at 9:55 PM, Dave Abrahams wrote: > > > on Fri Jul 01 2016, Matthew Johnson wrote: > >>> On Jul 1, 2016, at 6:32 PM, Dave Abrahams wrote: >>> >>> >>> on Fri Jul 01 2016, Matthew Johnson >>

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

I’m glad this was approved, the improvements look substantial! My one question is why are the bitwise operations (and/or/xor) modeled as member functions rather than operators? On Thursday, June 30, 2016, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Proposal link: >

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

-1 from me. I suggest to wait until we get generic protocols in Swift 4, then we can use the following: protocol From { init(_ from: T) } And deprecate all the weird Convertibles. ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

+0.5 - generally in favor, but I'm also leaning towards the "namespaced" alternative. > On Jul 2, 2016, at 1:07 AM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0115: Rename Literal Syntax Protocols" begins now and

Re: [swift-evolution] [Proposal] Sealed classes by default

> On Jul 2, 2016, at 12:42 AM, L. Mihalkovic > wrote: > > This is a situation I often run into in jave where I would use an enum to > create a finite set of constants to be passed (say action identifers). But > then this makes it very difficult for external

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

> Am 25.06.2016 um 22:03 schrieb L. Mihalkovic : > > > > Regards > (From mobile) > >> On Jun 25, 2016, at 8:48 PM, Thorsten Seitz wrote: >> >> >>> Am 25.06.2016 um 19:09 schrieb L. Mihalkovic : >>> >>> >>>

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

Hey Chris, Do you have plans to allow people to update Swift outside Xcode 8 point updates and still be able to submit to the App Store and benefit from the IDE's features? This could allow bug fixes to be delivered on a swifter way and take advantage of the fact that iOS is not including the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> * What is your evaluation of the proposal? Looks good to me. `RoundingRule.toNearestOrEven` is a fine name, but I would like the documentation to mention the term "bankers' rounding", a traditional term which Foundation uses for the same algorithm. (Actually, it might be a good idea to

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

Those aren't two "interchangeable" types in your example; it's the same type with two aliases. By contrast, the tuple types `(x: Int, y: Int)` and `(a: Int, b: Int)` are distinct, as I illustrated above. You are correct that one of the unique aspects of labeled tuple types would no longer be so

Re: [swift-evolution] [Proposal] Sealed classes by default

Regards (From mobile) On Jul 1, 2016, at 6:43 PM, John McCall via swift-evolution wrote: >>> On Jul 1, 2016, at 2:08 AM, Brent Royal-Gordon >>> wrote: >>> That starts to look an awful lot like a fifth access level just for classes >>> (I

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

This is IMHO a loophole in the type system today: '.Type' being a contextual keyword that is part of no protocol, there is no formal definition for what its return type and what can be done is purely driven by the compiler implementation. I used to have my oen bread of typeId until I ran into

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

typealias Point = (x: Int, y: Int) typealias Dimensions = (x: Int, y: Int) let point: Point = (x: 5, y: 5) let dimensions = point Fundamentally different concepts may have labels happen to be the same. Structs protect against this conversion, tuples don't. Explicit protocol conformance is

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

On Sat, Jul 2, 2016 at 1:03 AM, James Froggatt wrote: > Tuples are inherently interchangable. If you want to avoid this, the > safest way is to use a struct. > ``` typealias Foo = (a: Int, b: Int) typealias Bar = (c: Int, d: Int) var foo: Foo = (1, 2) var bar: Bar = (3,

Re: [swift-evolution] [Review] SE-0114: Updating Buffer "Value" Names to "Header" Names

> * What is your evaluation of the proposal? Oh, so *that's* what it's for. (That's a +1.) -- Brent Royal-Gordon Architechies ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

Tuples are inherently interchangable. If you want to avoid this, the safest way is to use a struct. Labels/naming shouldn't be relied on to provide type information, this is why implicit conformance to protocols is disallowed. From James F > On 2 Jul 2016, at 06:43, Xiaodi Wu