Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-12-04 Thread Dave Abrahams via swift-evolution
on Sun Dec 04 2016, Brent Royal-Gordon wrote: >> On Dec 1, 2016, at 2:09 PM, Dave Abrahams via swift-evolution >> wrote: >> >> More >> importantly, they suggest that the metatype argument will be used in >> some dynamic way (e.g. by calling a static method or an init), instead > >> of just as

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-12-04 Thread Ramiro Feria Purón via swift-evolution
*For what it's worth, I believe the pull request Anton mentioned above (>) addresses this.* And this proposal is suggesting moving away from the pattern/practice, rather than diving deeper into i

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-12-04 Thread Brent Royal-Gordon via swift-evolution
> On Dec 1, 2016, at 2:09 PM, Dave Abrahams via swift-evolution > wrote: > > More > importantly, they suggest that the metatype argument will be used in > some dynamic way (e.g. by calling a static method or an init), instead > of just as a way to get the right type inference. In some cases tha

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-12-02 Thread Dave Abrahams via swift-evolution
on Fri Dec 02 2016, Anton Zhilin wrote: > 2016-12-02 3:55 GMT+03:00 Ramiro Feria Purón : > >> *Unlike C++'s templates, a Swift's generic function is semantically a >> single function.* >> >> Anton, could you provide further insight on this? >> > > Basically, generic functions in Swift are implem

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-12-02 Thread Ramiro Feria Purón via swift-evolution
Anton, Thanks for the explanation. Interesting! I can understand the difference [I assume you are using the term template specialization (developer code to provide a special implementation for specific generic arguments) to refer to the term template instantiation (compiler generated code for a s

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-12-02 Thread Anton Zhilin via swift-evolution
2016-12-02 3:55 GMT+03:00 Ramiro Feria Purón : > *Unlike C++'s templates, a Swift's generic function is semantically a > single function.* > > Anton, could you provide further insight on this? > Basically, generic functions in Swift are implemented as functions taking an additional parameter -- w

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-12-01 Thread Ramiro Feria Purón via swift-evolution
*I might even be willing to inhibit deduction,by default, of all generic function type parameters that don't appear inthe parameter list.* ^ If this was adopted, what Dave is proposing is: func f() -> T // error: generic parameter T must be explicit func f() -> T // ok On Thu, 1

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-12-01 Thread Ramiro Feria Purón via swift-evolution
*Unlike C++'s templates, a Swift's generic function is semantically a single function.* Anton, could you provide further insight on this? On Fri, 2 Dec 2016 at 01:03 Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote: > I disagree with the suggestion. Unlike C++'s templates, a

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-12-01 Thread Ramiro Feria Purón via swift-evolution
*Yeah, this makes sense. Presumably this means that one could also write* * foo<>(1)* *where everything is still deduced. In C++, this syntax exists and means that non-template functions named “foo” are ignored.* Yes, it means so. One could have: foo() foo<>() // redundant foo<_>()

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-12-01 Thread Dave Abrahams via swift-evolution
on Wed Nov 30 2016, Douglas Gregor wrote: >> On Nov 30, 2016, at 4:09 PM, Dave Abrahams via swift-evolution > wrote: >> >> >> on Mon Nov 28 2016, Douglas Gregor >> >> > >> wrote: >> On Nov 21, 2016, at 3:05 PM, Ramiro Feria Purón via swift-evolution >>

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-12-01 Thread Goffredo Marocchi via swift-evolution
It seems odd that no review or comment has been made as the PR seems a step in the right direction. Sent from my iPhone > On 1 Dec 2016, at 14:17, Adrian Zubarev via swift-evolution > wrote: > > You forgot to mention Brent. ;) > > -- > Adrian Zubarev > Sent with Airmail > > Am 1. Dezember

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-12-01 Thread Adrian Zubarev via swift-evolution
You forgot to mention Brent. ;) --  Adrian Zubarev Sent with Airmail Am 1. Dezember 2016 um 15:03:07, Anton Zhilin (antonyzhi...@gmail.com) schrieb: I disagree with the suggestion. Unlike C++'s templates, a Swift's generic function is semantically a single function. One can say that together wi

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-12-01 Thread Anton Zhilin via swift-evolution
I disagree with the suggestion. Unlike C++'s templates, a Swift's generic function is semantically a single function. One can say that together with a metatype parameter, we pass in witness table. What I think we should do is make metatypes easier to use. *Adrian and I have a PR* that has already

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-30 Thread Douglas Gregor via swift-evolution
> On Nov 30, 2016, at 4:05 PM, Ramiro Feria Purón > wrote: > > Formally, perhaps the proposal should include the following: > > 1. Missing type parameters are assumed to be implicit and trailing (as in the > particular case of all type parameters missing). Yeah, this makes sense. Presumably

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-30 Thread Douglas Gregor via swift-evolution
> On Nov 30, 2016, at 4:09 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Nov 28 2016, Douglas Gregor > wrote: > >>> On Nov 21, 2016, at 3:05 PM, Ramiro Feria Purón via swift-evolution >> wrote: >>> >>> Problem: >>> >>> Currently, it is not p

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-30 Thread Dave Abrahams via swift-evolution
on Mon Nov 28 2016, Douglas Gregor wrote: >> On Nov 21, 2016, at 3:05 PM, Ramiro Feria Purón via swift-evolution > wrote: >> >> Problem: >> >> Currently, it is not possible to be explicit about the generic parameters >> (type parameters) in a > generic function call. Type parameters are infe

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-30 Thread Ramiro Feria Purón via swift-evolution
Formally, perhaps the proposal should include the following: 1. Missing type parameters are assumed to be implicit and trailing (as in the particular case of all type parameters missing). 2. _ is allowed as a placeholder when specifying explicit parameters in a function call. The corresponding pa

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-30 Thread Ramiro Feria Purón via swift-evolution
Or perhaps in a more "swifty" way, use _ for implicit type parameters, i.e.: f<_,T>() On Thu, 1 Dec 2016 at 01:13 Ramiro Feria Purón wrote: > Douglas, > > Regarding the question on the restriction for type parameters to appear on > the signature, the answer is remain. The proposal does not inte

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-30 Thread Ramiro Feria Purón via swift-evolution
Douglas, Regarding the question on the restriction for type parameters to appear on the signature, the answer is remain. The proposal does not intend this restriction to be lifted. One might expect to find a few legitimate cases where having it lifted would be handy or desirable. They seem to eme

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-30 Thread Goffredo Marocchi via swift-evolution
Sent from my iPhone > On 30 Nov 2016, at 06:40, David Hart via swift-evolution > wrote: > > For example, here is a design pattern I would find clearer with explicit type > information: > > let cat = factory.get() > > vs > > let cat: Cat = factory.get() > > Having the explicit type informa

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-29 Thread David Hart via swift-evolution
For example, here is a design pattern I would find clearer with explicit type information: let cat = factory.get() vs let cat: Cat = factory.get() Having the explicit type information in angle brackets allows us to move the type information closer to where it make sense. > On 29 Nov 2016, a

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-29 Thread Douglas Gregor via swift-evolution
> On Nov 29, 2016, at 8:00 AM, Derrick Ho via swift-evolution > wrote: > > I don't think the angle brackets adds any additional benefit than adding the > type information as a parameter. Adding Angle brackets will just make it > more crowded…. Adding the type information as a parameter effe

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-29 Thread Derrick Ho via swift-evolution
I don't think the angle brackets adds any additional benefit than adding the type information as a parameter. Adding Angle brackets will just make it more crowdedplus, the syntax just seems too much like c++ On Tue, Nov 29, 2016 at 8:43 AM Goffredo Marocchi via swift-evolution < swift-evolutio

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-29 Thread Goffredo Marocchi via swift-evolution
I think this is a case where the angle bran jets is both more readable and terse without losing context... opinions and all :). Sent from my iPhone > On 29 Nov 2016, at 09:47, Andrew Trick via swift-evolution > wrote: > > >>> On Nov 28, 2016, at 10:11 PM, Douglas Gregor via swift-evolution

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-29 Thread Andrew Trick via swift-evolution
> On Nov 28, 2016, at 10:11 PM, Douglas Gregor via swift-evolution > wrote: > >> >> On Nov 21, 2016, at 3:05 PM, Ramiro Feria Purón via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Problem: >> >> Currently, it is not possible to be explicit about the generic parameters

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-28 Thread Douglas Gregor via swift-evolution
> On Nov 21, 2016, at 3:05 PM, Ramiro Feria Purón via swift-evolution > wrote: > > 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)

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-22 Thread Haravikk via swift-evolution
> On 22 Nov 2016, at 04:18, Ramiro Feria Purón via swift-evolution > wrote: > > Thanks Dave! > > As another example, consider it as part of this common pattern: > > class A { > init() { > // .. > } > } > > class B: A { > override init() { > // .. > } > } > >

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-21 Thread Ramiro Feria Purón via swift-evolution
Thanks Dave! As another example, consider it as part of this common pattern: class A { init() { // .. } } class B: A { override init() { // .. } } class Factory { class func makeA() -> A { return B() } //.. } Factory.makeA() Kind regar

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-21 Thread Dave Abrahams via swift-evolution
on Mon Nov 21 2016, Ramiro Feria Purón wrote: > *Proposed Solution:* > > Allow explicit type parameters in generic function call: > > let _ = g(7)// Ok I think we want this capability, but it isn't a high priority and it's an additive feature so it's certainly out-of-scope for Swift

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-21 Thread Ramiro Feria Purón via swift-evolution
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 : > 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 p

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-21 Thread Derrick Ho via swift-evolution
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(type: T.Type, in vehicles: [Vehicle], condition: (Vehicle) -> Bool) -> [T] { return [] } processAll(type: Bicycle.self, in:

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-21 Thread Benjamin Spratling via swift-evolution
I don’t understand how your “contrived example" could be improved by this new feature instead of existing features. It sounds like you’re trying to combine two entirely different things into one function. One is a filter, which is easily made with .flatMap let vehicles:[Vehicle] = [Bicycle(), C

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-21 Thread Ramiro Feria Purón via swift-evolution
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 is the one to be called

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-21 Thread Sean Heber via swift-evolution
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 > wrote: > > Inferring the type of an expression from its surrounding context is not > necessarily an ideal f

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-21 Thread Ramiro Feria Purón via swift-evolution
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 "

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-11-21 Thread Adrian Zubarev via swift-evolution
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 noise on functions in Swift. --  Adrian Zubarev Sent with Airmail Am 22. November