Re: About type inference of method return value

On 08.09.2018 14:22, Jochen Theodorou wrote: On 07.09.2018 19:24, mg wrote: [...] The general, changing-return-type-only case for me falls under the responsibility of the developer: He will have to decide whether using type inference is the right choice here, and fix any potential future

Re: About type inference of method return value

- Mail original - > De: "Jochen Theodorou" > À: "dev" > Envoyé: Samedi 8 Septembre 2018 14:22:25 > Objet: Re: About type inference of method return value [...] > > "var" is a bit a different story. It will lead to surprising types

Re: About type inference of method return value

On 07.09.2018 19:24, mg wrote: [...] The general, changing-return-type-only case for me falls under the responsibility of the developer: He will have to decide whether using type inference is the right choice here, and fix any potential future errors that might occur if the inferred type

Re: About type inference of method return value

type inference in Groovy closures - or LINQ support ? Ursprüngliche Nachricht Von: Jochen Theodorou Datum: 07.09.18 09:03 (GMT+01:00) An: MG , dev@groovy.apache.org Betreff: Re: About type inference of method return value On 06.09.2018 20:51, MG wrote: [..] > The &

Re: About type inference of method return value

: Jochen Theodorou Datum: 07.09.18 09:03 (GMT+01:00) An: MG , dev@groovy.apache.org Betreff: Re: About type inference of method return value On 06.09.2018 20:51, MG wrote: [..] > The "int to long" inference example is an interesting special case that > I think would need to b

Re: About type inference of method return value

I have a dgeree in Theoretical Physics, and I would very much like to grasp the inferred type immediately ;-) That is exactly my point: Inferring obvious, simple cases is a good approach and brings the most benefit. I would call that "Groovy now supports return type inference in the obvious

Re: About type inference of method return value

Daniel, I am not 100% sure what you have in mind - the devil is always in the detail. Can it be written as a normal type checking extension class? Cheers, Paul. On Wed, Sep 5, 2018 at 2:50 PM Daniel Sun wrote: > Hi all, > > I am going to refine the type inference of method return value,

Re: About type inference of method return value

Am 06.09.2018 um 02:23 schrieb MG: Hi Jochen, but in what sense is any of these examples confusing for the user ? Type inference is not magic, and it can quickyl become a hard mathematical problem (https://en.wikipedia.org/wiki/Type_inference). And you as user do not have to understand

Re: About type inference of method return value

Hi Jochen, but in what sense is any of these examples confusing for the user ? Type inference is not magic, and it can quickyl become a hard mathematical problem (https://en.wikipedia.org/wiki/Type_inference). But in all that cases, we should just fall back to Object or throw. I don't know

Re: About type inference of method return value

On 05.09.2018 14:36, mg wrote: I agree with Daniel here, I also don't see how this could be confusing (?). Even if the inference mechanism falls back to inferring Object, the user will just get an "cannot call dadadam on Object" or such compile error - which should immediately leave to the

Re: About type inference of method return value

type needs to be given explicitely in this case... Does anyone have an example that shows such a malign/confusing type deduction case ? Ursprüngliche Nachricht Von: "Daniel.Sun" Datum: 05.09.18 14:02 (GMT+01:00) An: d...@groovy.incubator.apache.org Betreff: Re:

Re: About type inference of method return value

type needs to be given explicitely in this case... Does anyone have an example that shows such a malign/confusing type deduction case ? Ursprüngliche Nachricht Von: "Daniel.Sun" Datum: 05.09.18 14:02 (GMT+01:00) An: d...@groovy.incubator.apache.org Betreff: Re:

Re: About type inference of method return value

I just propose the smarter type inference for methods, which was in my TODO list. > We explicitly chose not to be too smart here, because it can be confusing > to users. OK. Recently I am developing a project based on Groovy. Writing code with "dynamic" mind and compile code in "static" way. So

Re: About type inference of method return value

This is another smarter type inference for `final`, which should work too if my proposal is supported by most of groovy users. Cheers, Daniel.Sun - Daniel Sun Apache Groovy committer Blog: http://blog.sunlan.me Twitter: @daniel_sun -- Sent from:

Re: About type inference of method return value

Sorry I don't understand what you are saying. What I'm saying is that we already had such an implementation, and we decided to _remove_ it. Are you saying that you have a branch that reintroduces it, or that it's already on master? I disagree with the statement that the "users require smarter

Re: About type inference of method return value

Hi Cédric, > Basically, it's not easy to realize that when you have a non final methods, subclasses can override the method to return a different type. As I proposed, the methods with smarter return type inference should match one of the following charactristics: 1) `final` 2) `private`

Re: About type inference of method return value

Hi Daniel, We discussed this when we implemented static compilation in the past. There were 2 different relates cases discussed: - smarter type inference for final fields - smarter type inference for final methods and decided not to implement them, so that it's not confusing for users when the

Re: About type inference of method return value

...@groovy.incubator.apache.org Betreff: About type inference of method return value Hi all,   I am going to refine the type inference of method return value, the methods should match one of the following charactristics: 1) `final` 2) `private` 3) `static` 4)  method defined in Script   The above methods

Re: About type inference of method return value

...@groovy.incubator.apache.org Betreff: About type inference of method return value Hi all,   I am going to refine the type inference of method return value, the methods should match one of the following charactristics: 1) `final` 2) `private` 3) `static` 4)  method defined in Script   The above methods

About type inference of method return value

Hi all, I am going to refine the type inference of method return value, the methods should match one of the following charactristics: 1) `final` 2) `private` 3) `static` 4) method defined in Script The above methods will not be overrided and have exact method return type.