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]
> <mailto:[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] <mailto:[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]
>> <mailto:[email protected]>>:
>> 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] <mailto:[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] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <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
