Re: [swift-evolution] [Pitch] Unifying init parameters with properties

-1 on #autoInit for properties declaration. Init should explicitly shows what parameters it will get and what will be assiged. I believe in case we want this feature, "self." prefix must be in init declaration in parameter list, with or without type(I prefer with type): init( self.foo: String,

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

> On 19 Apr 2016, at 00:14, Justin Jia via swift-evolution > wrote: > variadic functions are really easy to understand. > > For example: > > sum(x) > average(x) > NSLog("%d", x) > NSString.stringWithFormat("%d", x) I think the question really is whether not having to add square brackets is

Re: [swift-evolution] NSDate as struct in Swift Foundation (swift 3)

+1 IMO Date should be one of the standard type in Swift, like String, Array, Dictionary etc. And of course, it should be implemented as structure like any other base types in swift. It is very strange that NSDate(Date) was not introduced as standard type for Swift 3.0. But instead we are workin

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 14, 2016, at 4:55 PM, Stephen Canon via swift-evolution > wrote: > > /// `true` iff the signbit of `self` is set. Implements the IEEE 754 > /// `signbit` operation. > /// > /// Note that this is not the same as `self < 0`. In particular, this > /// property is true for `-0`

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 14, 2016, at 10:07 PM, Stephen Canon via swift-evolution > wrote: > >> On Apr 14, 2016, at 8:34 PM, Brent Royal-Gordon >> wrote: >> >>> Stephen Canon wrote: >>> >>> public protocol Arithmetic >> >> Is there a rationale for the name "Arithmetic"? There's probably nothing >> wrong

Re: [swift-evolution] [Pitch] Fully eliminate implicit bridging conversions in Swift 3

Is it true that some CF APIs, such as these, are still imported as CFString instead of String? https://github.com/apple/swift-3-api-guidelines-review/blob/swift-3/Platforms/OSX/CoreText/CTFontTraits.swift#L2-L9 On Mon, Apr 18, 2016 at 8:21 PM, Joe Pamer via swift-evolution < swift-evolution@swift

Re: [swift-evolution] [Proposal] Remove behavior on AnyObject that allows any obj-c method to be called on it

+1 for using a non implicit optional type. -Chris > On Apr 18, 2016, at 8:01 PM, Joe Pamer via swift-evolution > wrote: > > Just an update on this… (Sorry about the delay!) > > After experimenting with the changes outlined below, and discussing the > matter with a few folks off-list, it seem

[swift-evolution] [Pitch] Fully eliminate implicit bridging conversions in Swift 3

Hi everyone, Prior to Swift 1.2, conversions between bridged Swift value types and their associated Objective-C types could be implicitly inferred in both directions. For example, you could pass an NSString object to a function expecting a String value, and vice versa. In time we found this mo

Re: [swift-evolution] [Proposal] Remove behavior on AnyObject that allows any obj-c method to be called on it

Making things optional is fine; I would, however, like to give a strong -1 to the original proposal in which everything would have to be cast to an explicit type, since Cocoa contains APIs that give you objects of opaque types, returned as id/AnyObject, and expects you to be able to call methods

Re: [swift-evolution] [Proposal] Remove behavior on AnyObject that allows any obj-c method to be called on it

Just an update on this… (Sorry about the delay!) After experimenting with the changes outlined below, and discussing the matter with a few folks off-list, it seems like a better compromise would be to only adopt option #2. We would keep the direct member access syntax and wrap the results of an

Re: [swift-evolution] [META] Fast Track Reviews

Sent from my iPhone > On Apr 18, 2016, at 8:56 AM, Erica Sadun via swift-evolution > wrote: > > > I would like to see Swift Evolution adopt a couple of styles of fast track > reviews. Chris Lattner > suggested I bring this up on-list for discussion to allow the community to > offer feedbac

Re: [swift-evolution] NSDate as struct in Swift Foundation (swift 3)

Hi all, this is my first contribution here. I tried to track down if someone has posted something similar but I couldn’t find any mail. My proposal consists on making NSDate (or Date after the prefix removal) a struct instead of a class. I know that it was probably modeled as a class to keep com

Re: [swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters

Sent from my iPhone On Apr 18, 2016, at 4:11 PM, Robert Schwalbe via swift-evolution wrote: >> Hello Robert, >> >> My comment below: >> >>> Per my reading of SE-0022, would SE-0064 institute the first exception to >>> the #selector expression where the expression is not a reference to a >

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

+1 `prefix -=`, it logically follows :) -- Howard. On 19 April 2016 at 09:02, wrote: > "prefix -=“? > > (I’m not sure if I’m serious) > > - Dave Sweeris > > On Apr 18, 2016, at 5:57 PM, Howard Lovatt > wrote: > > I think `prefix -` works for `negated` (non-mutating form) but not > `negate` (

Re: [swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters

> Hello Robert, > > My comment below: > >> Per my reading of SE-0022, would SE-0064 institute the first exception to >> the #selector expression where the expression is not a reference to a method? > > Indeed. But I don’t see the issue. It still generates a selector for an > Objective-C method

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 18, 2016, at 4:52 PM, Dave Abrahams via swift-evolution > wrote: > >> > > Again you're encoding “I'm at the end” in the index, which as we've > agreed does not work. If nothing else, it works—and seems natural—for linked lists. Sorry; if I’d remembered this elementary example soo

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

Ah thanks! I forgot to select the Reply All option. My first email: >> Maybe you can check it out: >> >> https://github.com/JustinJiaDev/SwiftShell >> >> I prefer to write ls(.all, .longFormat) instead of ls([.all, .longFormat]). >> The former one looks a lot nicer. And it is much easier to t

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

"prefix -=“? (I’m not sure if I’m serious) - Dave Sweeris > On Apr 18, 2016, at 5:57 PM, Howard Lovatt wrote: > > I think `prefix -` works for `negated` (non-mutating form) but not `negate` > (mutating form). IE `-=` is the mutating form of `infix -` and there is no > equivalent in C-like la

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

I think `prefix -` works for `negated` (non-mutating form) but not `negate` (mutating form). IE `-=` is the mutating form of `infix -` and there is no equivalent in C-like languages for `negated` :( -- Howard. On 19 April 2016 at 08:28, wrote: > On Apr 16, 2016, at 6:12 PM, Howard Lovatt via

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

on Fri Apr 15 2016, Justin Jia wrote: > Hi! > > Currently, we can’t call a variadic function with an array of arguments. > > Reference: > 1. > http://stackoverflow.com/questions/24024376/passing-an-array-to-a-function-with-variable-number-of-args-in-swift > 2. https://www.drivenbycode.com/the-m

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

on Fri Apr 15 2016, Brent Royal-Gordon wrote: >> Given all this, I think it makes sense to go for syntactic >> uniformity between parameter list and function types, and just >> require parenthesis on the argument list. The types above can be >> trivially written as: >> >> (Int) -> Float >> (

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

on Thu Apr 14 2016, Chris Lattner wrote: > On Apr 14, 2016, at 10:21 PM, John McCall wrote: >> >>> On Apr 14, 2016, at 9:57 PM, Chris Lattner via swift-evolution >>> wrote: >>> >>> We currently accept function type syntax without parentheses, like: > >> To me, the unparenthesized style sugg

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 16, 2016, at 6:12 PM, Howard Lovatt via swift-evolution > wrote: > > For the Arithmetic protocol how about changing it to: > > protocol Arithmetic { > func + (lhs: Self, rhs: Self) -> Self > mutating func += (rhs: Self) -> Self > ... > } > > That way na

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

> All those points are also perfectly solved by dependent types How? What does print() or max() or ArrayLiteralConvertible have to do with dependent types? And what makes you think we're going to get dependent types, anyway? > I very very rarely use the print function with multiple parameters.

[swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

A Scala like new-Iterator pattern, using path-dependent typing, might be: struct Range { ... } func ..< (lowest: T, highest: T) { ... } struct Array: Collection { static struct Iterator { ... } // Note static ... func next(iterator: inout Iterator) -> Element? { ... } subscript(range: Range)

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

on Thu Apr 14 2016, Chris Lattner wrote: > We currently accept function type syntax without parentheses, like: > > Int -> Float > String -> () > > etc. The original rationale aligned with the fact that we wanted to > treat all functions as taking a single parameter (which was often of > tup

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 15, 2016, at 5:24 PM, Brent Royal-Gordon > wrote: > >> That’s the other part of my argument: if it is true that Swift code only >> needs to conform to ObjC protocols with optional requirements, but Swift >> code does not need to invoke optional requirements of ObjC protocols except

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

on Thu Apr 14 2016, Stephen Canon wrote: > Hi Howard, thanks for the feedback. > > On Apr 14, 2016, at 6:05 PM, Howard Lovatt > wrote: > > +1 great addition. > > Would suggest the naming could be more consistent, in particular: > > 1 Anything returning Self could be named xxxed

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

on Fri Apr 15 2016, Brent Royal-Gordon wrote: >>> Are there potential conforming types which aren't Comparable? >> >> Not at present, but I expect there to be in the future. Modular integers >> and complex numbers come to mind as the most obvious examples. > > Ooh, those are great examples. T

Re: [swift-evolution] [SR-933] Rename flatten to flattened

on Sat Apr 16 2016, Patrick Smith wrote: > Yes, I agree. I think in the guidelines should be a recommendation for > mutating methods are preferred, when nonmutating are preferred, and > when to have both. It would be interesting to see such a guideline. OK, off the cuff: Having a nonmutating

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Sun Apr 17 2016, Thorsten Seitz wrote: > The nonmutating forms successor/predecessor were fine. No need to > match them with the mutating ones IMO. Our API guidelines say that we should match them. We should have a better reason to depart from the API guidelines than “some people don't like

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Sat Apr 16 2016, Thorsten Seitz wrote: >> Am 15.04.2016 um 23:19 schrieb Dmitri Gribenko via swift-evolution >> : >> >> On Fri, Apr 15, 2016 at 1:30 PM, Stephan Tolksdorf wrote: >>> On 2016-04-12 Dmitri Gribenko via swift-evolution wrote: > Not even to mention that indices

Re: [swift-evolution] [Pitch] Unifying init parameters with properties

I agree with the intent of this, but perhaps not the solution; sticking with the original example, simply being able to have an implied initialiser for classes, as we have for structs, would be enough, for example: class Foo { let foo:String let bar:String let baz:Int

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Thu Apr 14 2016, plx wrote: >> On Apr 14, 2016, at 12:12 PM, Dave Abrahams via swift-evolution >> wrote: No, you can't, at least not usefully. An Index that's at the end of one collection is in the middle of another, or with a suitably-modified version of the same coll

Re: [swift-evolution] swift-evolution Digest, Vol 5, Issue 35

+1 for initializer over mapValues. One downside is that it’s impossible or very difficult to find documentation for Swift types (e.g. Dictionary) using Google, but I don’t think that this should impede considering this implementation. -1 for god methods. My concern is probably trivial but... if

Re: [swift-evolution] [META] Fast Track Reviews

> STYLE ONE: Minor language enhancements AKA "Low hanging fruit" > > I would like the core team to be able to add minor language enhancements > without going > through a formal proposal process, with its normal review overhead. I have > now been > involved in several reviews that involved API ch

[swift-evolution] [Accepted] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md Hello Swift Community, The review of SE-0059 "Update API Naming Guidelines and Rewrite Set APIs Accordingly” ran from March 31...April 5, 2016. The proposal is accepted. There was much deb

Re: [swift-evolution] [Pitch] Extend Any.Type to allow construction of bound generic types

> On Apr 17, 2016, at 7:13 AM, Joanna Carter via swift-evolution > wrote: > > I often find myself needing to construct an instance of a bound generic type > at runtime, in much the same manner as I would a "standard" type. > > e.g. > > As for a standard type… > > let aType = Int.Type > > l

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

- Dennis > On Apr 18, 2016, at 9:55 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> I would like to see format strings go away and be replace with safer inline >> annotations. > > The main problem is doing localized strings with printf-style formats well, > but I actually have a pre

[swift-evolution] [META] Fast Track Reviews

This makes perfect sense to me. +1 . ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

> I would like to see format strings go away and be replace with safer inline > annotations. The main problem is doing localized strings with printf-style formats well, but I actually have a pretty sweet solution for that: https://gist.github.com/brentdax/79fa038c0af0cafb52dd > -- E, somewhat

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

Part of me regrets using String(format:) as my go to example of a varargs invocation now. :) But while the train is off the rails, why introduce a special syntax at all? Since interpolation can include any expression, users can just write small formatting functions and call them there. Pros: We c

Re: [swift-evolution] [Draft] Expanded min/max algorithms

> On Apr 18, 2016, at 11:08 AM, Dmitri Gribenko wrote: > > On Sun, Apr 17, 2016 at 11:10 AM, Matthew Johnson via swift-evolution > wrote: >> These extension points are effectively “optional protocol requirements”. > > I'm sorry, but they are not optional requirements. They are > workarounds f

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

This is why god gave us bike sheds. Maybe "My earned interest rate this year is \({02.2}theRate)%!" -- E > On Apr 18, 2016, at 1:23 PM, Ricardo Parada wrote: > > What would that look like? > > > >> On Apr 18, 2016, at 3:06 PM, Erica Sadun via swift-evolution >> wrote: >> >> >>> On Apr

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

Let's build strings the same way we log String("\(authorOfAutoLayoutMasterBook) could you please show \(canICountHowMany) times more love to \(ToolThatBuildsInterfaces) :)") ^_^ ? [[iOS messageWithData:ideas] broadcast] > On 18 Apr 2016, at 20:06, Erica Sadun via swift-evolution > wrot

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

What would that look like? > On Apr 18, 2016, at 3:06 PM, Erica Sadun via swift-evolution > wrote: > > >> On Apr 18, 2016, at 1:01 PM, Tony Allevato via swift-evolution >> wrote: >> >> I would also be supportive of removing varargs for now, in favor of a >> rethought design when generics

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

I think it’s pretty clear that if we have a syntax for passing an array to a variadic argument it should be: func(array…) This would be symmetric with variadic type signature, and similar to how other languages do it (i.e. in Ruby, declaration is `*args` and array splat is also `*args`

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

> On Apr 18, 2016, at 1:01 PM, Tony Allevato via swift-evolution > wrote: > > I would also be supportive of removing varargs for now, in favor of a > rethought design when generics are completed. > > In their current form, varargs are fairly limited—because they're mapped onto > an array, th

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

I would also be supportive of removing varargs for now, in favor of a rethought design when generics are completed. In their current form, varargs are fairly limited—because they're mapped onto an array, the argument types must be homogeneous, so either your function can only usefully take a singl

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

About print() and similar: this should be (in case we remove variadic params) overloaded functions with different number of params. func print() func print(v1: Any) func pring(v1, v2: Any) etc As for #splat. Should we have such problems in working with params or should we introduce one more la

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

Justin Jia via swift-evolution writes: > > Hi!Currently, we can’t call a variadic function with an array of arguments. IMO, this would be a useful addition. Here are my thoughts on the thread so far as an imaginary Q&A. "Why not remove vararg instead?" As others have mentioned, this feature e

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

+1 to remove them(vararg) or introduce special marker for variadic params. IMO: I think variadic parameters is alien construction in Swift, where we expect that the method call explicitly tells us what is the purpose of each parameter by using external param names. Plus, variadic parameters a

Re: [swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters

Hello Robert, My comment below: > Per my reading of SE-0022, would SE-0064 institute the first exception to the > #selector expression where the expression is not a reference to a method? Indeed. But I don’t see the issue. It still generates a selector for an Objective-C method. > In the spir

Re: [swift-evolution] [META] Fast Track Reviews

+2. I think both of these processes, if practical for the team, would benefit the community. There are lots of PRs that have sat open for months with no response. Another idea: track evolution proposals on the bugs.swift.org JIRA installation, by cr

Re: [swift-evolution] [Proposal] mapValues

I like the idea of having a mapping method which maps back to the actual type. What about a more general approach? consider: mappedSelf(transform: T -> U) -> Self filteredSelf(includeElement: T -> Bool) -> Self Which can be added to other collections like Set and sequences like a lazy number seq

Re: [swift-evolution] [Accepted] SE-0048: Generic Type Aliases

> On Apr 16, 2016, at 4:12 PM, Chris Lattner wrote: > > >> On Apr 16, 2016, at 1:12 AM, Nicola Salmoria via swift-evolution >> wrote: >> >>> Proposal link: >>> https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md >>> >>> The review of SE-0048 “Generic Ty

Re: [swift-evolution] [Draft] Expanded min/max algorithms

On Sun, Apr 17, 2016 at 11:10 AM, Matthew Johnson via swift-evolution wrote: > These extension points are effectively “optional protocol requirements”. I'm sorry, but they are not optional requirements. They are workarounds for a language issue -- inability to make conditionally-available method

[swift-evolution] [META] Fast Track Reviews

I would like to see Swift Evolution adopt a couple of styles of fast track reviews. Chris Lattner suggested I bring this up on-list for discussion to allow the community to offer feedback on my idea. STYLE ONE: Minor language enhancements AKA "Low hanging fruit" I would like the core team to

Re: [swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters

I realize I am quite late to this discussion, so if a public flogging is in order I am willing to accept that (and the rest of this e-mail can be ignored and/or deleted from the archives). Per my reading of SE-0022, would SE-0064 institute the first exception to the #selector expression where t

[swift-evolution] [Idea] Passing an Array to Variadic Functions

Hi! Currently, we can’t call a variadic function with an array of arguments. Reference: 1. http://stackoverflow.com/questions/24024376/passing-an-array-to-a-function-with-variable-number-of-args-in-swift 2. https://www.drivenbycode.com/the-missing-apply-function-in-swift/ Consider the following

Re: [swift-evolution] [Draft] Expanded min/max algorithms

> On Apr 17, 2016, at 9:42 AM, Nate Cook via swift-evolution > wrote: > > > On Apr 17, 2016, at 8:46 AM, plx via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> I like the idea. It worries me a bit if the general recipe for such >> situations is to add dedicated-purpose met

Re: [swift-evolution] [Proposal] Add keyword "by" as syntactic sugar to streamline For-In-loop

Right now it seems for me that for-in + "step" is the best solution that provides what we need with minimal changes : for i in 0..<10 step 2 { } for i in 0..<10 step -2 { } for i in 0.1..<10.5 step 0.5 { } ("step" is optional) i.e. like current for-in loop, but with additional features. On

Re: [swift-evolution] Feature proposal: Range operator with step

On 15.04.2016 3:57, Hans Huck via swift-evolution wrote: > Anyway, why not just make it .step() then, like in Ruby? > > Instead of a "by" keyword, I'd be happy with syntactic sugar in the form of > > for i in p1..As for 'step' word: It seems like for now IMO this is the best suggestion : very exp

Re: [swift-evolution] What about a VBA style with Statement?

Agree. Such construction is also very useful. +1 to implement it. From one side we know, that we should name variables with meaningful names. From other side, the longer the name of variable - the more noise you see in code and in some cases this noise,copy-paste,ide completion suggestions pro

Re: [swift-evolution] What about a VBA style with Statement?

As for methods cascades, IMO it is a good feature and I support it as addition to 'with' feature. Method cascading can't be used to set/get values of multiply props, the main purpose of 'with' I strongly feel that functions is not a solution for 'with' feature. Functions add additional complexi

Re: [swift-evolution] [SR-933] Rename flatten to flattened

+1, almost totally agree. IMO sort/map/filter/reduce/etc "belongs" to the functional word, as I can see Swift is moving to be more functional language, we like to use functional features like some.filter{}.map{}.reduce{}, we like such frameworks/libs like RxSwift/ReacriveCocoa, we are implemen

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

> Why not remove varargs altogether from Swift, it is easy enough to put [] > round a list? +1 I think it's much less useful than tuple-splat, Swifts array-syntax is very lightweight and "…" adds complexity that is rarely needed.___ swift-evolution mai

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

+1 I am against introducing more parentheses because the resulting code is much more unreadable IMO (those additional parentheses will typically appear in argument lists, which means that the additional parentheses will be nested in the parentheses of the argument list). As someone else said, t

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

On 16.04.2016 5:00, Jacob Bandes-Storch via swift-evolution wrote: I believe the community is in agreement about the following: • The "allValues" behavior should be provided by conformance to some protocol, named ValueEnumerable or ValuesEnumerable or similar. • The compiler should deri

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

Hm, sorry but I’m still not convinced :( I still find it confusing and I think if it wasn’t in Swift already, it would not be added. Maybe someone can come up with a strong reason why it should be added if it weren’t there. - Dennis > On Apr 18, 2016, at 10:10 AM, Gwendal Roué wrote: > > >>

Re: [swift-evolution] [Pitch] Unifying init parameters with properties

-1 on this. After the parameter declaration we expect to see a type of that parameter. I don't think we should break Swift method declarations for this feature. I prefer to see information about parameter types in func/init declaration. I don't want to scroll up to the start of class declaration

Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

Thanks Gwendal, that makes sense - for the case where Shape is a protocol. Since the OP wasn't clear about it, I tried the original example with both the cases where Shape was declared as a protocol (i.e. Circle conforms) and where Shape was declared as a class (i.e. Circle inherits). The same pro

Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

Those "trampolines" are visible in debugger stack traces, or in Instruments, as "protocol witness" function calls. You may have seen them already. You see, a variable of type SomeProtocol, or the result of a method that returns a protocol, does not contain a value of any concrete type that adopt

Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

I’m actually not sure what the next step is. What is the official way to submit the proposal for the Swift team to consider? > > Le 18 avr. 2016 à 12:01, Yogev Sittona écrit : > > > > I’m referring you to Ross O’Brien’s post: > > As of Swift 2.2, if a variable has a closure type of e.g. () ->Sha

Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

You may have to explain that metaphor (or link to an explanation) - what is 'trampoline' data? On Mon, Apr 18, 2016 at 11:11 AM, Gwendal Roué wrote: > > > Le 18 avr. 2016 à 12:01, Yogev Sitton a écrit : > > > > I’m referring you to Ross O’Brien’s post: > > As of Swift 2.2, if a variable has a c

Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

> Le 18 avr. 2016 à 12:01, Yogev Sitton a écrit : > > I’m referring you to Ross O’Brien’s post: > As of Swift 2.2, if a variable has a closure type of e.g. () -> Shape, a > closure of type () -> Circle would be considered a match. If a class > implements 'func make() -> Shape', a subclass imp

[swift-evolution] [Proposal] Custom operators

Sorry for the delay, please mail me a copy next time :) Inline: Антон Жилин: > > No new suggestions have come in 2 days, and so I have created a pull > request! > > https://github.com/apple/swift-evolution/pull/253 > 1. Assignment operators in Swift 2.2 have an `assignment` keyword: > infix opera

Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

I’m referring you to Ross O’Brien’s post: As of Swift 2.2, if a variable has a closure type of e.g. () -> Shape, a closure of type () -> Circle would be considered a match. If a class implements 'func make() -> Shape', a subclass implementing 'func make() -> Circle' has to override. However, if

Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

> Le 18 avr. 2016 à 11:53, Yogev Sitton a écrit : > > Hi Gwendal, > > I’m actually trying to start a discussion that will change the current > behavior of the language. > That’s why I posted this on the swift-evolution mailing list and not > swift-users. OK Yogev. But what is the problem act

Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

That’s exactly my point - thank you for the quick summary Ross. Protocols behaves differently than closures and classes. > On Apr 18, 2016, at 12:40 PM, Ross O'Brien > wrote: > > As of Swift 2.2, if a variable has a closure type of e.g. () -> Shape, a > closure of type () -> Circle would be co

Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

Hi Gwendal, I’m actually trying to start a discussion that will change the current behavior of the language. That’s why I posted this on the swift-evolution mailing list and not swift-users. Yogev > On Apr 18, 2016, at 12:48 PM, Gwendal Roué wrote: > > Hello Yogev, > > I think your question

Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

Hello Yogev, I think your question belongs to the swift-users mailing list (quoting https://lists.swift.org/mailman/listinfo): - swift-evolution: Discussion of the evolution of Swift, including new language features and new APIs. - swift-users: For users to get help with or ask questions about

Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

As of Swift 2.2, if a variable has a closure type of e.g. () -> Shape, a closure of type () -> Circle would be considered a match. If a class implements 'func make() -> Shape', a subclass implementing 'func make() -> Circle' has to override. However, if a protocol requires a 'func make() -> Shape'

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

I agree with Gwendal. I think it is a feature that is nice to have with few drawbacks. Personally I prefer the first solution. > On Apr 18, 2016, at 1:10 AM, Gwendal Roué wrote: > > Gwendal ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> Am 18.04.2016 um 08:16 schrieb Dmitri Gribenko : > >> On Sun, Apr 17, 2016 at 11:14 PM, Thorsten Seitz wrote: >> Preventing indices of one collection being used by another collection can be >> done by using path dependent types like in Scala. >> >> Then 'i' would have type a.Index (where 'a'

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

> Le 18 avr. 2016 à 10:02, Dennis Weissmann a écrit > : > > That’s IMO already a problematic case: > >> DatabaseTable.select(id, name).order(name, id) // What’s the >> problem? >> // vs. >> DatabaseTable.select([id, name]).order([name, id]) // OK, of >> course...

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

That’s IMO already a problematic case: > DatabaseTable.select(id, name).order(name, id) // What’s the > problem? > // vs. > DatabaseTable.select([id, name]).order([name, id]) // OK, of > course... But some people will find it a litle short The problem is that yo

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

> Le 18 avr. 2016 à 09:35, Dennis Weissmann via swift-evolution > a écrit : > >> Why not remove varargs altogether from Swift, it is easy enough to put [] >> round a list? > > +1, that was my thought too. I can’t think of a use case where you can’t use > an array instead of varargs (this ass

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

> Why not remove varargs altogether from Swift, it is easy enough to put [] > round a list? +1, that was my thought too. I can’t think of a use case where you can’t use an array instead of varargs (this assumes all vararg parameters are converted to array parameters). - Dennis > On Apr 18, 20