Ah yes, Stack not Number, that was just me checking whether a false case
was detected and I forgot to change it back.
On Sat, Jun 6, 2020 at 3:24 PM Jochen Theodorou wrote:
> On 06.06.20 06:57, Paul King wrote:
> > Here is a good example for your point Jochen:
> >
> > ///
> > @gr
On 06.06.20 06:57, Paul King wrote:
Here is a good example for your point Jochen:
///
@groovy.transform.TypeChecked
def method() {
def component = new Random().nextBoolean() ? new ArrayDeque() : new Stack()
component.clear() // 'clear' in LUB (AbstractCollection or Seri
Here is a good example for your point Jochen:
///
@groovy.transform.TypeChecked
def method() {
def component = new Random().nextBoolean() ? new ArrayDeque() : new
Stack()
component.clear() // 'clear' in LUB (AbstractCollection or Serializable
or Cloneable)
if (component
On 04.06.20 21:45, Daniil Ovchinnikov wrote:
[...]
If we do not give up on flow typing, then I would like to
know why the assignment should not be legal. And if it is legal in the
if-branch, then why not in the Closure block?
All assignments should be legal, and assignment in Closure block as
eed to use block instead of closure or add a typecast or type
> checking extension
> }
>
> -Original Message-----
> From: Jochen Theodorou
> Sent: Thursday, June 4, 2020 11:35 AM
> To: dev@groovy.apache.org
> Subject: Re: STC: Closure shared variable assignment handling
typeOf ... *at* this point
Sorry.
> On 4 Jun 2020, at 22:45, Daniil Ovchinnikov
> wrote:
>
> Hi -
>
>> Of course if we want to define intuitive as "do it like Java", we make
>> def an alias for var, take its semantics and give up on Flow typing in
>> general.
>
> Nobody wants to give up fl
Hi -
> Of course if we want to define intuitive as "do it like Java", we make
> def an alias for var, take its semantics and give up on Flow typing in
> general.
Nobody wants to give up flow typing.
> If we do not give up on flow typing, then I would like to
> know why the assignment should n
On 04.06.20 18:55, Milles, Eric (TR Tech, Content & Ops) wrote:
I am suggesting that when a closure is encountered, it is treated like an
optional branch of the code. So assignments within alter the inferred type the
same way an assignment within an if with no else would.
sure I am for that,
// new behavior: STC error because "b()" is not a member of A; user
would need to use block instead of closure or add a typecast or type checking
extension
}
-Original Message-
From: Jochen Theodorou
Sent: Thursday, June 4, 2020 11:35 AM
To: dev@groovy.apache.org
Subject
On 04.06.20 17:07, Milles, Eric (TR Tech, Content & Ops) wrote:
There are a couple open bugs related to STC handling of closure shared
variables. When a shared variable is assigned a value within the
closure, the assigned type is not included in the inferred type outside
the closure/lambda and t
There are a couple open bugs related to STC handling of closure shared
variables. When a shared variable is assigned a value within the closure, the
assigned type is not included in the inferred type outside the closure/lambda
and this leads to some problems.
If this behavior is changed to sav
11 matches
Mail list logo
