Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a way to determine if a collection is const #23327

Closed
DartBot opened this issue Apr 25, 2015 · 5 comments
Closed

Add a way to determine if a collection is const #23327

DartBot opened this issue Apr 25, 2015 · 5 comments
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug

Comments

@DartBot
Copy link

DartBot commented Apr 25, 2015

This issue was originally filed by davidm...@google.com


Here...

new MyClass(const [1, 2, 3]);

...MyClass has to do a defensive copy to protect against unexpected mutates later. If collection literals implemented a marker interface this could be avoided.

MyClass(List<int> ints) {
  _ints = ints is ConstList
      ? ints
      : new List<int>.from(ints);
}

@lrhn
Copy link
Member

lrhn commented Apr 27, 2015

Being constant is not a property of an object alone, it also depends on all the object's members to be constant as well. It's a deep recursive property.

That said, there is some work being done on detecting and using deep immutability that may be useful in general. For example, using a const constructor with known immutable arguments will always generate an immutable object, even when using "new" with the constructor.

So, I don't think a marker interface is the best way to go - it's not something an interface can promise anyway, and it won't apply as often as one could want (an UnmodifiableListView wrapper would not be immutable unless the list it wraps is also unmodifiable).


Added Area-Library, Triaged labels.

@DartBot
Copy link
Author

DartBot commented Apr 27, 2015

This comment was originally written by davidm...@google.com


I understand that it's a hard problem generally.

But most of it can be solved with the type system or with generated code. e.g. the built collections library, and generated builders.

The one thing that can't be done as an extension is literals, for convenience. That needs language support. Const literals are already what's needed, but don't work because there's no way to check for them.

@DartBot
Copy link
Author

DartBot commented Apr 27, 2015

This comment was originally written by davidm...@google.com


Just realized my issue title is wrong, I meant "if a collection is a const literal".

Maybe this is too much of a special case, but it's all I need ;)

@DartBot
Copy link
Author

DartBot commented May 1, 2015

This comment was originally written by davidm...@google.com


It seems Map already does what I'm asking for: a const map is an ImmutableMap, so I can write "is ImmutableMap".

Would it be possible to do the same for list literals?

@DartBot DartBot added Type-Enhancement area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. labels May 1, 2015
@lrhn
Copy link
Member

lrhn commented Dec 17, 2015

We still have not introduced a way to distinguish collections that come from compile-time constant expression from other collections. It isn't really a property of the object, it's just how the object was made. The ImmutableMap class only exists in the VM, and it can also be used for other maps created at runtime (in fact, the Map.unmodifiable constructor uses it too).

While constant maps and lists usually have special types, they are not publicly visible types, so you can't test against that, and it wouldn't work for non-map/list const objects anyway.

We don't currently plan to add a way to distinguish compile-time constants from other objects.

(There is a hack: A compile-time constant sent through a SendPort preserves its identity, while other objects are copied. I don't recommend trusting this, but it currently works on the VM).

@lrhn lrhn closed this as completed Dec 17, 2015
@lrhn lrhn added the closed-not-planned Closed as we don't intend to take action on the reported issue label Dec 17, 2015
@kevmoo kevmoo added type-enhancement A request for a change that isn't a bug and removed triaged labels Mar 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

3 participants