Silver: collection types are treated as reference objects, not value objects

Elements Elements Bugs
1

IDE: Fire
Version: 8.3
Target (If relevant): Java
Description:

Swift defines its collection primitives (Arrays, Dictionaries, Sets) as value objects, but Silver treats them as references.

var a = ["hello"];
var b = a;
b.append("there");

Expected Behavior:

a == ["hello"]
b == ["hello","there"]

Actual Behavior:

a == ["hello","there"]
b == ["hello","there"]
2

Known difference and as designed. Struct based collection classes that behave performant and with copy-on-write semantics are a no-go omn Java and .NET, due to runtime limitations. Our options for making [] and [:] structu are:

  • absolutely sucky performance, where every modification would cause a copy
  • unpredictable data consistency when structs leave the scope of of what where our compiler can control their copying (eg when adding them to a generic list type provided by the .NET or Java runtime.

neither of the alive are acceptable, and there’s absolutely the no workaround for the second option. That’s why we opted for making these two types reference based.

3

then how do we copy it intentionally?

4

I see. And personally I find Apple’s design wrt collection value types bizarre, even contemptuous, but that’s what they did.

5

indeed. someone on he swift team doesn’t understand and is afraid of OOP.

6

Oh, I know other teams like that :grinning: :cry: :innocent:
And where they believe everything that was introduced during the last 30 years is bad and from the devil.

1 Like
7

you should be able to just do:
var y = [String](org);

to copy it

1 Like