make "a = []" do the right thing when a is of a known type

[Kurper]

var a as List<of int>?
(...)
a = []

would be nice to be able to do. Same for dicts/sets, presumably.

[hopscc]

Sorta related see  Setting the type of an empty list

[hopscc]

Working on allowing setting explicit type of {List, Array, Set, Dict} lits.

[hopscc]

patch, lotta tests and relnote for supporting composite Literals being explicitly typed
and assigning empty composite literals to a known type variable.

(Composite Literals are the literal forms for Lists, Sets, Dicts and Arrays)

e.g
alist as List<of int> = [] # this was original suggested enhancement
alist2 = [] as List<of int>

[Charles]

after 0.9

[Charles]

bump. but won't get to this before 0.9.2

[Charles]

(1)
The patch breaks self-hosting of the compiler. I boiled it down to a little test case:

class A

    var _d as dynamic?

    def foo
        _d = []
        
    def bar
        a as dynamic?
        a = []
        
    def main
        .foo
        .bar

(2)
And this still fails after patch application:

class A

    cue init
        base.init
        .stuff = {:}
    
    pro stuff from var as Dictionary<of String, dynamic?>

    def main
        print 'done.'

Regarding the above, I don't interpret the ticket as being limited to local variables even though no additional examples were provided. I don't see why any lvalue couldn't be acceptable...?

(3)
I don't see why the keyword would be "as" instead of "to". We already use "to" for casting including cases like "to !" and "to ?", while "as" has been used only for declarations. "[] as List<of int>" is not a declaration, especially if it can be used anywhere an expression can be used such as passing an argument to a method.

# to - casting:
x to int
t to !
z to ?
[] to List<of int>

# as - declaring:
var x as int

def foo(c as char)

def bar
    x as int

All things considered, using "to" for this related feature makes more sense rather than overloading "as" for something different than declarations.

(4) I'll be re-uploading the patch right after this with the two test cases and bit rot fixed.

[Charles]

two new test cases; patch rot fixed

[hopscc]

I'll have to look at what 1) is doing now
2) still fails cos its still wrong:

.stuff is explicitly declared as a Dict<of String, Dynamic?) and the initialiser is assigning a literal of (defaulted type ) Dict<of String, Object> to it - the two are not compatible according to the backend compiler

what you should be able to do (with the patch) is
either declare and initialise .stuff directly from an empty (correctly typed )literal

 pro stuff from var = {:} as Dictionary<of String, dynamic?>
# stuff is an empty Dictionary<of String, dynamic?)

or assign a (now) correctly typed literal to it

class A

    cue init
        base.init
        .stuff = {:} as Dictionary<of String, dynamic?>
         # the empty Dict above is correctly and explicitly typed same as stuff

    
    pro stuff from var as Dictionary<of String, dynamic?>

3) The keyword is as because conceptually it actually is a declaration (with explicitly specified type) of the literal AND an initialisation to the provided values - for an empty literal non default type cannot be correctly inferred...

Using the casting to implies that the literal is default typed (<String,Object?> for Dict) and then up/down cast to the desired type ( which may or may not be valid for a normal declaration with or without whatever co and contravariance the underlying compiler/back-end supports ( Dict<MyClass?, Object> for e.g.)

"[] as List<of int>" is not a declaration

But it is - its a declaration of a literal as an empty List of ints just as
[] is a declaration of a literal as an empty List<of Object>

The Literals are both a declaration of type and an initialisation of values - its less apparent for non empty values because the types are inferred and are usually
what you want from that - the explicit type decl allows more specific typing than the defaulting/inferring which is mostly only really useful for starting with an empty collection that you subsequently want to fill...

I'll look at the bitrot fixed patch and see what is happening with 1)

[hopscc]

Re 1) Convenience for assigning empty lits was retyping literal to target type dynamic when it should not have been - corrected

Re 2) Sorry I misunderstood what you were talking about - an expansion of the ticket and patch to support lvalues other than local vars - same as what it does for local vars... so done for dot expressions... Its possible to support others (what would they be ??) but its veering into more complex exprs where it may be better to make the conversion/empty lit type explicit...

patch coming up...

[hopscc]

New patch - dynamic issue corrected, fixed new test
clean test pass