Wiki

Ticket #230 (assigned enhancement)

Opened 7 years ago

Last modified 4 years ago

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

Reported by: Kurper Owned by: Chuck
Priority: minor Milestone:
Component: Cobra Compiler Version: 0.8.0
Keywords: Cc:

Description

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

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

Attachments

assign-empty-type-lits.patch Download (39.7 KB) - added by hopscc 7 years ago.
ticket-230-b.patch Download (39.3 KB) - added by Charles 4 years ago.
two new test cases; patch rot fixed
ticket-230-c.patch Download (40.3 KB) - added by hopscc 4 years ago.

Change History

Changed 7 years ago by hopscc

Changed 7 years ago by hopscc

  • status changed from new to assigned
  • owner set to hopscc

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

Changed 7 years ago by hopscc

Changed 7 years ago by hopscc

  • owner changed from hopscc to Chuck

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>

Changed 5 years ago by Charles

after 0.9

Changed 5 years ago by Charles

bump. but won't get to this before 0.9.2

Changed 4 years ago by Charles

  • owner changed from Chuck to hopscc

(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.

Changed 4 years ago by Charles

two new test cases; patch rot fixed

Changed 4 years ago by 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)

Changed 4 years ago by 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...


Changed 4 years ago by hopscc

Changed 4 years ago by hopscc

  • owner changed from hopscc to Chuck

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

Note: See TracTickets for help on using tickets.