Re: [swift-evolution] Required Callback

Gordon wrote: > > On Aug 16, 2016, at 12:44 PM, James Campbell via swift-evolution < > swift-evolution@swift.org> wrote: > > > > That sounds fair, the closure that function returns could trigger a > runtime warning when it detects the closure has be deallocated without

Re: [swift-evolution] Required Callback

In this case the @required callback is something *all* implementations should use for the mentioned reasons (memory leaks etc) just to clarify :). *___* *James⎥Lead Hustler* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsb

Re: [swift-evolution] Required Callback

02:49, Boris Wang wrote: > Why the callback is special ? > > The compiler should has a warning for unused parameters of function. > > I think this is enough. More works should be leaved for a lint tool. > > > James Campbell via swift-evolution 于2016年8月17日 > 周三06:39写道： &

Re: [swift-evolution] Required Callback

​I'm not sure about that last question, I guess someone who knows more about it than me could answer.​ *___* *James⎥Lead Hustler* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 16 A

Re: [swift-evolution] Required Callback

@noescape is a hint that the callback will only be called once and allows compiler to optimise, we may or may not be able to combine @required functionality into that but it looks like it was rejected for now. @required is a compiler hint / sanity check to enforce that the callback is actually cal

Re: [swift-evolution] Required Callback

hadn't adpated the @required property so >>>>>>>> you >>>>>>>> get both compatibility, safety and clarity. >>>>>>>> >>>>>>>> *___* >>>>>>>> &

Re: [swift-evolution] Required Callback

>>> *___* >>>>>>> >>>>>>> *James⎥Lead Hustler* >>>>>>> >>>>>>> *ja...@supmenow.com ⎥supmenow.com >>>>>>> <http://supmenow.com>* >>>>>

Re: [swift-evolution] Required Callback

gt;> >>>>> On 16 Aug 2016, at 15:49, Xiaodi Wu via swift-evolution < >>>>> swift-evolution@swift.org> wrote: >>>>> >>>>> I can see the use case, but it'd be annoying (or, impossible) to work >>>>> around if I intend to

Re: [swift-evolution] Required Callback

d by that other module, and if calling >>> `end` twice causes bad things to happen, I'm totally out of luck. You'd >>> need a companion annotation to pass along the requirement to the callee, or >>> some sort of force-unrequire, but the latter can't have te

Re: [swift-evolution] Required Callback

causes bad things to happen, I'm totally out of luck. You'd > need a companion annotation to pass along the requirement to the callee, or > some sort of force-unrequire, but the latter can't have teeth (i.e. can't > enforce at runtime) if the closure is escaping. > On

Re: [swift-evolution] Required Callback

s no way for the compiler to >>> inspect that `end` is always called by that other module, and if calling >>> `end` twice causes bad things to happen, I'm totally out of luck. You'd >>> need a companion annotation to pass along the requirement to the callee, or &g

Re: [swift-evolution] Required Callback

to pass along the requirement to the callee, or > some sort of force-unrequire, but the latter can't have teeth (i.e. can't > enforce at runtime) if the closure is escaping. > On Tue, Aug 16, 2016 at 08:39 James Campbell via swift-evolution < > swift-evolution@swift.org&g

[swift-evolution] Required Callback

It would be handy if a callback could be marked as required with an optional descriptive message i.e class BackgroundTask { func run(end: @required("You must call end otherwise iOS will penalise your app for being a bad citizen") () -> Void) } That was the developer can comunicate the bad things

Re: [swift-evolution] An Alternative for Extensibility Modifiers

I think sealing classes already existi in Swift it's called Private :) *___* *James⎥Head of Trolls* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 12 July 2016 at 12:20, Charlie Mon

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Personally I think a great compromise is just forcing the user to use the `override` keyword when subclassing in these cases. That way the library maker can mark classes that aren't supported or are internal and ideally shouldn't be used by the programmer. However we shouldn't baby sit programmers

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

-0.5 I think preventing subclassing is a bad idea, sometimes there are bugs which can only be resolved by subclassing and this removes a lot of power from app makers. On 6 July 2016 at 13:23, Jacopo Andrea Giola via swift-evolution < swift-evolution@swift.org> wrote: > > * What is your eval

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

What would be a better alternative is the ability to have a String Format Token that would unwrap a value, like so let string = String(format: "http://%?/";, url) None is unwrapped to "http:///"; Some is unwrapped to "http://myurl.com/"; I think this would be a good trade off rather than having

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

t; > let popUpButton: NSPopUpButton = ... > for kind in MediaKind.allKinds { > popUpButton.addItemWithTitle(kind.localizedName) > } > > And many, many more. > > > On Jul 5, 2016, at 12:33 PM, James Campbell via swift-evolution < > swift-evolution@swift.org>

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

Would love a real life scenario of why you would need this. *___* *James⎥Head of Trolls* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 4 July 2016 at 02:36, Gabriel Lanata via swif

Re: [swift-evolution] Shorthand unwrap proposal

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

Re: [swift-evolution] Shorthand unwrap proposal

one or zero times, so there’s no ambiguity. > > Jordan > > > On Jun 23, 2016, at 09:15, James Campbell via swift-evolution < > swift-evolution@swift.org> wrote: > > So I have a real-life situation in an application, which does what you > mention: > > This code

Re: [swift-evolution] Shorthand unwrap proposal

meter to something that > does not take an optional. > > I don’t have a solution - just trying to clarify the situation. :) > > l8r > Sean > > > > On Jun 23, 2016, at 10:36 AM, James Campbell via swift-evolution < > swift-evolution@swift.org> wrote: > > > &g

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

-1 Where provides a nice clarity when distinguishing the clauses from the optional binding *___* *James⎥Head of Trolls* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 23 June 2016 a

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

Big step forward, no longer have to do this : https://gist.github.com/jcampbell05/f6b5611bd7f61840edb10500fa69fd09 *___* *James⎥Head of Trolls* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A

Re: [swift-evolution] Shorthand unwrap proposal

eallyLongOptionalName! { > doSomethingWith(myReallyLongOptionalName) > } > > > > > On Jun 23, 2016, at 5:36 PM, James Campbell via swift-evolution < > swift-evolution@swift.org> wrote: > > I was wondering if people would be open to adding an unwrap method to the > Optional type, I a

Re: [swift-evolution] Shorthand unwrap proposal

nsbury Square* *London* * EC2A 1AF * On 23 June 2016 at 16:56, Dmitri Gribenko wrote: > On Thu, Jun 23, 2016 at 8:36 AM, James Campbell via swift-evolution > wrote: > > I was wondering if people would be open to adding an unwrap method to the > > Optional type, I already have

[swift-evolution] Shorthand unwrap proposal

I was wondering if people would be open to adding an unwrap method to the Optional type, I already have a method like this which shortens code for me. So this: let myReallyLongOptionalName: String? = "Hey" if let string = myReallyLongOptionalName { doSomethingWith(string) } Could become" le

Re: [swift-evolution] the "guard" keyword, again

I think unless has always made more sense, guard felt like a multithreaded statement as in guard this variable from other threads. *___* *James⎥Head of Trolls* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *

Re: [swift-evolution] Initialiser Helper

p Swift 4. > > Sent from my iPad > > On May 23, 2016, at 8:24 AM, James Campbell via swift-evolution < > swift-evolution@swift.org> wrote: > > I would like to be able to use functions to help me initilise a class or > struct so I can break down a init into seperate

[swift-evolution] Initialiser Helper

I would like to be able to use functions to help me initilise a class or struct so I can break down a init into seperate methods, like so: struct Person { let age: Int init (json: Dictionary) { // lots of code age = json["age"] } } This can become un-wieldly, so I would love to be able to do

[swift-evolution] [Swift 4] Support an official reactive library

With swift 3 around the corner, I wanted to propose some higher level focuses for version 4. My first suggestion is an official reactive library. Reactive programming has gained a huge amount of popularity especially with reactive cocoa and rxswift. Microsofts support of the original Rx library i

Re: [swift-evolution] Auto Unwrapping Of Optionals

That would be handy Sent from Supmenow.com On Sat, Apr 30, 2016 at 1:31 PM -0700, "David Sweeris via swift-evolution" wrote: On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution wrote: I think this specific proposal asking for compiler magic to auto-unwrap invisibly and o

Re: [swift-evolution] Auto Unwrapping Of Optionals

Wouldn't calling the NSDate constructor escape the context ? Sent from Supmenow.com On Fri, Apr 29, 2016 at 1:47 PM -0700, "Tod Cunningham via swift-evolution" wrote: Adrian, excellent example of a challenging case. I would say that when calling any method that might mutate the v

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

What if we had a concept similar to errors and try ? Given this function: func sort() -> Self { } mutating sort() -> Self { } If a developer calls: array.sort() It will sort a copy of that array, in order to sort in place the developer must confirm the mutation like so: mutate array.sort()

Re: [swift-evolution] Shortcut for creating arrays

Exactly  Sent from Supmenow.com On Fri, Apr 8, 2016 at 9:38 AM -0700, "Ross O'Brien" wrote: A function that splits by whitespace would be this: "h j c k".componentsSeparatedByCharactersInSet(NSCharacterSet.whiteCharacterSet()) 'componentsSeparatedByWhitespace' might be a nice addi

Re: [swift-evolution] Shortcut for creating arrays

Pehaps we could have a function that splits by whitespace. "h j c k".split() *___* *James⎥Alex's Minder* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 8 April 2016 at 15:05, Ross

Re: [swift-evolution] Generic Alaises

6, 2016 at 9:05 PM, Milos Rankovic via swift-evolution wrote: Chris Lattner has a proposal under review on this topic.  milos On 6 Apr 2016, at 20:41, James Campbell via swift-evolution wrote: This was inspired from the topic about moving where clauses out of parameter lists. Certain generics ge

[swift-evolution] Generic Alaises

This was inspired from the topic about moving where clauses out of parameter lists. Certain generics get very long winded, I was wondering if we could create some sort of alias for generics. func anyCommonElements (lhs: T, _ rhs: U) -> Bool could be shared across functions like so: genericalia

Re: [swift-evolution] [Proposal] Custom operators

In these case of module operator conflicts perhaps there could be a way we could import these operators ? Likes a #importOperators(OtherModule) or some kind of build flag. *___* *James⎥Future Prime Minister* *ja...@supmenow.com ⎥supmenow.com

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

What about private, fileonly, moduleonly, public ? *___* *James⎥Future Prime Minister* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On Thu, Mar 31, 2016 at 1:24 PM, Pierre Monod-Broc

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

What about local for a file only or scope definition ?  Sent from Supmenow.com On Wed, Mar 30, 2016 at 12:39 PM -0700, "Jordan Rose via swift-evolution" wrote: Ah, sorry! Those are all clear to me; it's the possibility of writing some other module name there that would have the wr

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

* What is your evaluation of the proposal? I think this is a positive step in the right direction but I think there still needs to be more amendments. So a +1 if address the issues I'm about to outline. Anything not annotated should be imported as an optional not a IUO, this makes it safer to h

Re: [swift-evolution] Promote "primitive" types to enums in extensions

I would rather have a syntax that mirrors the way Protocol does it. struct Card { suit:enum value:Int } or we could change it so this only excepts the enum itself unless you explicitly cast from a Int or another enum: struct Card { suit:CardSuit value:Int } *

Re: [swift-evolution] struct subtyping

I was treating this as a Mixin. So the property from Object is Mixed into Tree and User but it isn't a Subclass so any comparison between the two isn't possible. But on reflection you bring up a very valid point. *___* *James⎥Head Of CEO* *ja...@supmenow.com ⎥su

Re: [swift-evolution] Deprecating Trailing Closures

I think the feature should stay but we need community guidelines on when and when not to use them. *___* *James⎥Head Of CEO* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On Thu, Mar

Re: [swift-evolution] struct subtyping

Would love a way of extending an existing struct as a new type but it not being related to the struct it extends. Sort of like a mixin but for structs, so I could have: struct Object { let identifier: String } struct User: Object { } struct Tree: Object { } The last two structs get the identi

Re: [swift-evolution] idea: immutable setters for structs and tuples?

Could we draft up a proposal :) *___* *James⎥Head Of CEO* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On Wed, Mar 23, 2016 at 10:49 PM, Rudolf Adamkovic via swift-evolution < swift-

Re: [swift-evolution] idea: immutable setters for structs and tuples?

Yeah a way to have a function that mutates a struct return a new copy with that mutation would be awesome ! Rather than mutating in place. *___* *James⎥Head Of CEO* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Squar

Re: [swift-evolution] [Draft] Abolish IUO type

One thing I've had bit me is the lack of some sort of confirmation, see this example. I have a objective-c method in a library like so: - (void)observe:(CallbackBlock)block; The CallbackBlock is a type def-ed block like so: typedef void (^CallbackBlock)(FDataSnapshot *snapshot); The parameter

[swift-evolution] Potential Bug with Compiler in 2.1.1 and UnitTests

I have a class that specifies a initialiser taking any class that implements the protocol "ChatDatastore" I can use this fine in the functions for my test cases. However if I try to initialise it in a member either statically, lazily or even via a computed variable it shows an error stating "Inst

Re: [swift-evolution] [Draft] Abolish IUO type

One thing I've had bit me is the lack of some sort of confirmation, see this example. I have a objective-c method in a library like so: - (void)observe:(CallbackBlock)block; The CallbackBlock is a type def-ed block like so: typedef void (^CallbackBlock)(FDataSnapshot *snapshot); The parameter

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Just wondering, wouldn't private be enougth for a class level declaration ? Not sure why we need a file baed one. *___* *James⎥Head of Trolls* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A

Re: [swift-evolution] removeFirst, optional equiviliant

Yeah I was using this for a LIFO type system :) glad to know there is a method for this. On Thu, Jan 7, 2016 at 12:09 AM, Dave Abrahams wrote: > > On Jan 6, 2016, at 3:48 PM, Jacob Bandes-Storch > wrote: > > Whoops, I meant append()/popFirst. That is, even for a single-ended queue, > you'll use

[swift-evolution] Improve Number Type

There is a number of deficiencies with Swift and Numbers. Especially when trying to be clever with generics. - The API exposes built in types like`BuiltIn.Word` as the return type of some APIs but there is no way to use said types. - We have a Float and a Float80. Float and Doubles can't be initia

[swift-evolution] SignedNumberType

What is the purpose of this type ? Why don't we have UnsignedNumberType --  Wizard ja...@supmenow.com +44 7523 279 698 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Explicity Size Clipping

t;> >> >> does not compile ("foo.swift:10:22: error: cannot convert value of type >> 'UInt32' to expected argument type 'Int'"). >> >> Félix >> >> Le 6 janv. 2016 à 13:17:03, James Campbell a écrit : >> >> protoco

Re: [swift-evolution] removeFirst, optional equiviliant

lic/core/RangeReplaceableCollectionType.swift#L235> >> already >> handles empty array scenario by failing if the precondition is not met. >> Or do you have something else in mind? >> >> max >> >> On Jan 6, 2016, at 9:36 AM, James Campbell via swift-evolution

Re: [swift-evolution] Explicity Size Clipping

(value) > > } > > } > > > > Without that last method, Swift tries to give the UInt32 to the Int > version of the method which isn't safe in my eyes and I would have expected > a compiler error. > > On Wed, Jan 6, 2016 at 6:14 PM, Félix Cloutier wrote: >

Re: [swift-evolution] STDLibs

I did but it redirects elsewhere now :S On Wed, Jan 6, 2016 at 6:50 PM, Erica Sadun wrote: > Have you stopped by swiftdoc.org <http://swiftdocs.org> recently? > > :) > > -- Erica > > > On Jan 6, 2016, at 3:43 AM, James Campbell via swift-evolution < > swif

Re: [swift-evolution] STDLibs

Chris do you think there is scope for this ? On Wed, Jan 6, 2016 at 2:38 PM, Trent Nadeau wrote: > Big +1 from me. Rust's docs do this well too across trait implementations. > > On Wed, Jan 6, 2016 at 5:43 AM, James Campbell via swift-evolution < > swift-evolution@swift

Re: [swift-evolution] removeFirst, optional equiviliant

ctionType.swift#L235> > already > handles empty array scenario by failing if the precondition is not met. > Or do you have something else in mind? > > max > > On Jan 6, 2016, at 9:36 AM, James Campbell via swift-evolution < > swift-evolution@swift.org> wrote: > &

Re: [swift-evolution] Explicity Size Clipping

> Le 6 janv. 2016 à 13:02:43, James Campbell via swift-evolution < > swift-evolution@swift.org> a écrit : > > I have a overloaded method for a protocol that takes an Int or double. > > I have an issue with swift calling the Int version when passing in a > UInt32 . Ideally

[swift-evolution] Explicity Size Clipping

I have a overloaded method for a protocol that takes an Int or double. I have an issue with swift calling the Int version when passing in a UInt32 . Ideally I would prefer the compiler to detect I am about to do something which will cause an overflow and throw an error. I would then have to expli

[swift-evolution] removeFirst, optional equiviliant

If you call removeFirst and the array is empty it would be great if it was optional so it could return nil or at least it threw an error so you could handle that case. --  Wizard ja...@supmenow.com +44 7523 279 698 ___ swift-evolution mailing list swif

Re: [swift-evolution] Support for newtype feature/typesafe calculations

I've managed to implement this already in the language with a few ugly corners due to the lack of generic protocols. I created a protocol based on Box (https://github.com/robrix/Box/) which works really well. I have extended this to handle certain special protocols like Equatable so you can do Spe

Re: [swift-evolution] Type Safe Algorithms

handled that (a bulky old TI Voyage 200, though I think that the N-Spire > line can do it too). > > Félix > > Le 6 janv. 2016 à 10:17:23, James Campbell via swift-evolution < > swift-evolution@swift.org> a écrit : > > I implemented a way of type safeing a calculation in Swi

[swift-evolution] Type Safe Algorithms

I implemented a way of type safeing a calculation in Swift. I.e marking an Int as a Degree and then being able to convert to a Radian. (At the bottom of the page) The magic for these special structs was the AngleType protocol which allows you to Box up a value (in this case a number) and it handle

Re: [swift-evolution] Rename "guard" to "unless"

Should we add this to the list of things requested that will be rejected ? On Wed, Jan 6, 2016 at 10:58 AM, Greg Parker wrote: > > > On Jan 6, 2016, at 2:09 AM, James Campbell via swift-evolution < > swift-evolution@swift.org> wrote: > > > > What is "

[swift-evolution] STDLibs

Is there a way of improving the documentation and hosting it on Swift instead of Apple ? Currently the Array page lists all of the things the class directly implements but doesn't include any of the methods mixed in by protocol extensions (i.e all of the methods from CollectionType). With YardDoc

[swift-evolution] Rename "guard" to "unless"

What is "guard"? why its the opposite to "if"! So in other languages what have they called this, well in Ruby they called it "unless" which I feel is a much clearer form of intent and lower barrier of entry for a user. See this code. guard name != nil else { fatalError("Please enter a name") }

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

We should add an unless one to compliement it :) unless foo? { } On Wed, Jan 6, 2016 at 6:16 AM, Thorsten Seitz via swift-evolution < swift-evolution@swift.org> wrote: > +1 > > Type narrowing would also fit nicely with union types (as demonstrated in > Ceylon). > > -Thorsten > > Am 05.01.2016 um

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

Is there a reason we need a Double as well as a Float ? I see the value in Int and Float butt could they not both be the biggest value supported on the platform? Usually when mapped to Objective-C Swift values become NSIntegers anyways which I don't believe is a pure float or double. On Tue, Jan

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

x27; cannot be used with > array literal > var distanceCache: [Int: Int] = [] > ^~ > > That should address the problem, thanks for pointing this out! > > -Chris > > On Jan 5, 2016, at 4:51 AM, James Campbell via swift-evolution < >

[swift-evolution] Default lazy constructor

When creating a lazy variable, maybe we should allow for default closures, i.e lazy var userSession: UserSession Which will construct that object for you instead of having to do: lazy var object: MyObject { let userSession = UserSession() return userSession }() If the initial

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

the > equivalent array syntax i.e. > > var array = [Int]() > var dictionary = [String: Int]() > > > > > On Tue, Jan 5, 2016 at 12:50 PM, Jeremy Pereira < > jeremy.j.pere...@googlemail.com> wrote: > > I don’t understand what the problem is > > > > >

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

The problem for me is that is so counter intuitive I didn't even know you could do that. On Tue, Jan 5, 2016 at 12:50 PM, Jeremy Pereira < jeremy.j.pere...@googlemail.com> wrote: > I don’t understand what the problem is > > > On 5 Jan 2016, at 12:39, James Campbell via sw

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

Perhaps instead of "auto" we could allow "lazy" to create a default lazy constructor for these cases ? On Tue, Jan 5, 2016 at 12:39 PM, James Campbell wrote: > See this code: > > var distanceCache: [Int: Int] = Dictionary() > It is very long and tedious to write especially if what I am storing >

[swift-evolution] Be able to initialise empty dict with array constrcutor

See this code: var distanceCache: [Int: Int] = Dictionary() It is very long and tedious to write especially if what I am storing changes. I propose we be allowed to do the following: *var distanceCache: [Int: Int] = []* If this isn't possible then I wouldn't mind having some way of telling the

Re: [swift-evolution] Then Support

ugs.swift.org/browse/SR-160 > > The topic appears to be a popular one and well liked. I understand its > best timeframe for discussion will be in about a year as it is unlikely to > be addressed in Swift 3.0, although you should probably ask an Apple team > member rather than

[swift-evolution] Then Support

I was wondering if this should be part of the stdlib https://cocoapods.org/pods/Then --  Wizard ja...@supmenow.com +44 7523 279 698 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

This is a relevant article https://www.mikeash.com/pyblog/friday-qa-2015-12-25-swifty-targetaction.html?utm_campaign=iOS%2BDev%2BWeekly&utm_medium=email&utm_source=iOS_Dev_Weekly_Issue_231 For this topic Sent from my iPhone > On 31 Dec 2015, at 01:33, James Campbell wrote: > > Good point. Not

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

Good point. Not sure if that's replaceable via a protocol or if that Api is just not suited for swift. There is a proposal somewhere to be able to reference swift methods via back ticks a sort of selector for swift so maybe in this case we would use that. Sent from my iPhone > On 30 Dec 2015,

Re: [swift-evolution] Proposal: Add function SequenceType.find()

; for elt in self { > if try thatSatisfies(elt) { > return elt > } > } > return nil > } > } > > [1, 2, 3, 4, 5].first(thatSatisfies: (Int) throws -> Bool) > > [1, 2, 3, 4, 5].first { $0 > 3 } > >> On 30 Dec 2015,

Re: [swift-evolution] Proposal: Add function SequenceType.find()

lf.Generator.Element? { > for elt in self { > if try thatSatisfies(elt) { > return elt > } > } > return nil > } > } > > [1, 2, 3, 4, 5].first(thatSatisfies: (Int) throws -> Bool) > > [1, 2, 3, 4, 5].first { $0 > 3 } >

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

I'm not as familiar with OS X but why is it vital there ? Also for Linux this api is unneeded since there is no access to objective c Sent from my iPhone > On 30 Dec 2015, at 16:06, Tino Heth <2...@gmx.de> wrote: > > >> Ah good point, in swift you can return a function as a closure (see that

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

Do you have an example of use ? Sent from my iPhone > On 30 Dec 2015, at 15:48, Félix Cloutier wrote: > > How do you import the API to Swift when the target and action properties are > separate? > > Félix > >> Le 30 déc. 2015 à 09:36:24, James Campbell via s

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

015, at 14:14, Jean-Daniel Dupas wrote: > > >> Le 30 déc. 2015 à 12:21, James Campbell via swift-evolution >> a écrit : >> >> These are very good points. >>> >>> Actually, it comes in as addAction(action: Selector), not String. You can >>

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

Totally agree with that proposal, I think we should do that as a temporary step but also look to reduce the need for selectors in favour of closures. As I think a lot of the behaviour of selectors Could be replicated by existing swift features. Sent from my iPhone > On 30 Dec 2015, at 12:54,

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

In the performSelector and nsinvocation case. Are people using it for existing functions in which case type safety is important. But if it's for dynamic calling of a method ( for example for a visitor pattern) then I don't think there is any safety that can easily be applied via a special synt

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

These are very good points. > > Actually, it comes in as addAction(action: Selector), not String. You can > initialize a Selector from a string literal. Yes :) should have looked it up before I tried to remember it off the top of my head. > > Three questions about your proposal: > > 1. Wher

Re: [swift-evolution] Proposal: Add function SequenceType.find()

We should add the full collection of ruby methods http://matthewcarriere.com/06/23/using-select-reject-collect-inject-and-detect/ Sent from my iPhone > On 30 Dec 2015, at 02:40, Keith Smiley via swift-evolution > wrote: > > +1. We've added an extension for this and find it very useful. >> O

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

What if selectors arguments could be imported into swift to take a closure instead ? This would fit into the proposal to rewrite the imported objective c Apis So - addAction:(Selector)action Becomes addAction(action:(AnyObject)->Void) Instead of addAction(action:String) Like it does no

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

What if you could just refer to it by pointing to a special property ? button.addTarget( class.prototype.handlePress) If it has parameters these could be specified like so button.addTarget(class.prototype.handlePress(sender:)) Sent from my iPhone > On 29 Dec 2015, at 21:46, Joe Groff via swif

Re: [swift-evolution] rename dropFirst() and dropLast()

What about shift and pop? They both could take an argument of a number of items to shift or pop ? Sent from my iPhone On 29 Dec 2015, at 20:25, Brent Royal-Gordon via swift-evolution wrote: >> I guess that's a good argument for keeping "prefix" and "suffix" instead of >> "take" and "takeE

Re: [swift-evolution] ternary operator ?: suggestion

What if you could wrap the existing switch statement in a closure and return a value from that closure like so Let value = { switch (other) { Case .Some(let value): Return value // because this is in a closure the closure will return the value not the function this is in Case .None: Return "hell

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

s known to always eat Grass; with the > generic type, every function is written to handle all foodstuffs. > > So, no, the two different syntaxes are required - but protocols with > generic parameters (is that the right term for e.g. Grass in > Animal?) would be a good addition to the langua

Re: [swift-evolution] Adding custom attributes

Maybe we could implement a template system like C++ On Sat, Dec 26, 2015 at 3:20 PM, Dmitri Gribenko via swift-evolution < swift-evolution@swift.org> wrote: > On Sat, Dec 26, 2015 at 3:59 PM, Radosław Smogura > wrote: > > So, > > > > What do you think about syntax like this: > > > > // Declarati

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

to a >> protocol, you can ask about the types that X uses to implement the >> requirements of the protocol". I guess we could call them "related types" >> instead of "associated types", but that doesn't seem significantly >> different. >> >&

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

; > instead of "associated types", but that doesn't seem significantly > different. > > Jordan > > > > On Dec 23, 2015, at 12:42, James Campbell via swift-evolution < > swift-evolution@swift.org> wrote: > > > > The thing is associated type m

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

The thing is associated type means nothing to me, it's too technical. Placeholder type I think would be better even if it's only what we called it in the documentation Sent from my iPhone > On 23 Dec 2015, at 20:35, Chris Lattner via swift-evolution > wrote: > > >> On Dec 23, 2015, at 9:59

  1   2   >