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
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
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. I am not looking to
examine the code flow and distinguish between closure executed im
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,
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
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
