Cobra Forums

Chuck I know you are busy with the Java backend, so I didn't want to bother with this question which may have a trivial answer that I don't know about. So maybe the community can help me out here:

Code: Select all

class Prog
    def main
        print .add([1, 2, 3], 4)

    def add(a as List<of int>, b as int) as List<of int>
        r = []
        for v in a
            v = v + b
            r.add(v)
        return r


gives me the error:

Cannot implicitly convert type "System.Collections.Generic.List<object>" to "System.Collections.Generic.List<int>"

Somehow I need to tell the compiler that 'r' is a list of ints when I initialize it. Because when I change the above to 'r = [2]' (or any other int in place of 2) it works. I tried 'r = int[]' but that didn't seem to work. Also did not find anything on how to set the type of an empty list on this page: http://cobra-language.com/how-to/UseLists/

Thanks for any help you can provide.

For now you have to use:

I would like to add something in the future that works with the empty literal:

Idea B would need a syntax for multiple args like dictionaries.

(Now that your first post have been moderator approved, your subsequent posts will show immediately.)

Both of those are 'new' syntax unlike existing typing forms
alternatively support

Code: Select all

r as List<of int> = []


i.e special case 'as <Type> = []' as idiom on declarations meaning "initialize to empty sequence of specified type"
ditto 'as <Type> = {:}' for Dicts
and 'as <Type> = {} for Sets'

or
Probably better and conforms to existing cobra typing syntax
Allow an extension to the Literal empty {List, Dict, Set} syntax to specify typing same as for vars/variables

Code: Select all

r = [] as List<of int>
s = {} as Set<of int>
d = {:} as Dict<of String, int>


The Typing is optional of coaurse and if not specified does same type inference (or whatever) as now

Another (existing cobraish) aternative would be to overload the casting syntax for this case

Code: Select all

r = [] to List<of int>
d = {:} to Dict<of String, int>


Thanks Chuck; that worked. I would have never guessed the empty parentheses. At one point I also guessed:

Code: Select all

r = [] as List<of int>

and it didn't work and I really thought it should have. This seems most intuitive, so I would suggest using this syntax.

I like hopscc's idea for:
I was already talking to kurper in irc about supporting "_foo = []" and that fits in with that.

By itself, it's not sufficient since the need to dictate the collection type comes up in circumstances other than assignment, such as passing an argument. This brings us to hopscc's suggestions for "as" and "to". The "to" seems most natural since we already use it in expressions; "as" is only used in declarations.

Also, this need comes up for non-empty literals. Consider that you might want the type to be more general:
Omar, the reason that list creation is "List<of T>()" with parens is that the parens are the general way to instantiate a type. Basically, Java's "new Foo()" is simply "Foo()" in Cobra (and Python).

Thanks for the comments and thoughts.

I'm working on the explicit typing of {List,Set, Dict} ( and array for completeness) Literals (just have Dict to go)

To my way of thinking this conceptually should be using 'as' rather than 'to' since you are declaring the literal (defining its contents AND
declaring its type explicitly ) rather than defining content then casting/reconverting its type to something less or more specific up or down its inheritance chain.
also FWIW C# disallows those types of casts (List<of Object> -> List<of SpecificType>) implicitly or explicitly (presumably without some form of conversion support)

Code: Select all

shapes = [Circle()] as List<of Shape>

# explicitly thats :
shapes as List<of Shape> = List<of Shape>()
shapes.add(Circle())

# vs something like

shapes as List<of Circle> = List<of Circle>()
shapes.add(Circle())
shapes to List<of Shape>


I'll take a look at the assignment of empty literals to the declared variable type after that.

I'm traveling today and almost out the door, but I thought C# supported those types of assignments in C# 4.0. See http://kohari.org/2008/10/28/generic-variance-in-c-40/

We're targeting .NET 2.0 still but the point is that we're heading in that direction.

Should have noted this when I uploaded it.
patch supporting this now on ticket:230.

Handles both the topic of this discussion (setting the type explicitly on an empty composite literal) and the
topic for the ticket (allowing an unspecified type empty Composite Literal type to be assigned to a Composite variable which is already compatibly typed)