Derrick, This proposal is nothing but adding built-in language support for the code you have just written.
Regards, Ramiro 2016-11-22 12:40 GMT+11:00 Derrick Ho <[email protected]>: > If you want to feed it a type rather than infer it from variable type or > cast it using as! Then you can just add the type as a parameter… > > func processAll<T: Vehicle>(type: T.Type, in vehicles: [Vehicle], > condition: (Vehicle) -> Bool) -> [T] { > > > return [] > } > > processAll(type: Bicycle.self, in: [Vehicle()], condition: {_ in true}) > > On Nov 21, 2016, at 8:24 PM, Ramiro Feria Purón via swift-evolution < > [email protected]> wrote: > > Yes, it does; as it does let processedCars: [Car] = processAll(in: > vehicles, condition: aboveSpeedLimit) > > The core of the matter is that it is nowhere stated in the call > (expression) processAll(in: vehicles, condition: aboveSpeedLimit) that > the specialised version processAll<Bicycle> is the one to be called. > > Although we are aware of the semantics, it does not read naturally and is > somehow confusing. The ultimate goal is to make swift cleaner and clear. It > rather feels like invoking non-specialised, non-generic function, and then > casting the result to an array of a given type, which is not the case. > > All the best, > Ramiro > > 2016-11-22 12:09 GMT+11:00 Sean Heber <[email protected]>: > >> Doesn't this work? >> >> processAll(in: vehicles, condition: aboveSpeedLimit) as [Bicycle] >> >> l8r >> Sean >> >> Sent from my iPad >> >> On Nov 21, 2016, at 6:11 PM, Ramiro Feria Purón via swift-evolution < >> [email protected]> wrote: >> >> Inferring the type of an expression from its surrounding context is not >> necessarily an ideal feature in a strongly typed programming language. >> >> The goal here is to be able to be explicit about the type, in an elegant >> and clear way, especially when there is no (need for a) context. >> >> Note that the <Type> "noise" would only be necessary when the type could >> not be inferred from the actual parameters (and if the current surrounding >> context type inference was removed, which is not part of the proposal). >> >> The line of code from the Motivation that does not compile is: >> >> processAll<Bicycle>(in: vehicles, condition: aboveSpeedLimit) >> // This should be allowed under this proposal >> >> 2016-11-22 10:35 GMT+11:00 Adrian Zubarev <[email protected] >> om>: >> >>> I’m not sure what are you trying to solve here. Your code from the >>> motivation compiles just fine in my Playground. >>> >>> About the g function: >>> >>> g(7) as [String] >>> let _: [String] = g(7) >>> >>> Personally I don’t like to see <Type> noise on functions in Swift. >>> >>> >>> >>> -- >>> Adrian Zubarev >>> Sent with Airmail >>> >>> Am 22. November 2016 um 00:06:02, Ramiro Feria Purón via swift-evolution >>> ([email protected]) schrieb: >>> >>> *Problem:* >>> >>> Currently, it is not possible to be explicit about the generic >>> parameters (type parameters) in a generic function call. Type parameters >>> are inferred from actual parameters: >>> >>> func f<T>(_ t: T) { >>> >>> >>> //.. >>> } >>> >>> f(5) // T inferred to be Int >>> f("xzcvzxcvx") // T inferred to be string >>> >>> If no type parameter is involved in the formal parameters, the type >>> parameter needs to be used somehow as part of the return type. For example: >>> >>> func g<T>(_ x: Int) -> [T] { >>> >>> >>> var result: [T] = [] >>> >>> >>> //.. >>> >>> >>> return result >>> } >>> >>> In such cases, the type parameters must be inferrable from the context: >>> >>> g(7) // Error: T cannot be inferred >>> let array = g(7) // Error: T cannot be inferred >>> >>> let array: [String] = g(7) // Ok: T inferred to be String >>> let array = g<String>(7) // Error: Cannot explicitly specialise >>> generic function >>> >>> >>> >>> * Proposed Solution:* >>> >>> Allow explicit type parameters in generic function call: >>> >>> let _ = g<String>(7) // Ok >>> >>> >>> >>> *Motivation:* >>> >>> Consider the following contrived example: >>> >>> class Vehicle { >>> var currentSpeed = 0 >>> //.. >>> } >>> >>> class Bicycle: Vehicle { >>> //.. >>> } >>> >>> class Car: Vehicle { >>> //.. >>> } >>> >>> @discardableResult >>> func processAll<T: Vehicle>(in vehicles: [Vehicle], condition: (Vehicle) >>> -> Bool) -> [T] { >>> >>> >>> var processed: [T] = [] >>> >>> >>> for vehicle in vehicles { >>> guard let t = vehicle as? T, condition(vehicle) else { continue >>> } >>> //.. >>> processed.append(t) >>> } >>> >>> >>> return processed >>> >>> } >>> >>> func aboveSpeedLimit(vehicle: Vehicle) -> Bool { >>> return vehicle.currentSpeed >= 100 >>> >>> } >>> >>> >>> let processedVehicles = processAll(in: vehicles, condition: >>> aboveSpeedLimit) // Uh, T inferred to be Vehicle! >>> >>> let processedCars: [Car] = processAll(in: vehicles, condition: >>> aboveSpeedLimit) // T inferred to be Car >>> >>> processAll<Bicycle>(in: vehicles, condition: aboveSpeedLimit) >>> // This should be allowed under this proposal >>> >>> >>> *Notes:* >>> >>> If necessary, the (real life) Swift code that lead to the proposal could >>> be shared. >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
