03_How does Dart handle collections like List, Set, and Map in terms of immutability?

In Dart, collections like List, Set, and Map are mutable by default, meaning we can add, remove, or modify their elements after creation. However, Dart also provides ways to make them immutable (read-only) — which is useful for maintaining data integrity and preventing accidental changes, especially in state management or shared data scenarios.

Let me explain each case clearly:

1. Mutable Collections (Default Behavior)
Normally, when we create a List, Set, or Map, they are modifiable.

void main() {
  var list = [1, 2, 3];
  list.add(4); // ✅ Works
  print(list); // [1, 2, 3, 4]

  var set = {10, 20};
  set.add(30); // ✅ Works
  print(set); // {10, 20, 30}

  var map = {'name': 'Aswini'};
  map['age'] = 25; // ✅ Works
  print(map); // {name: Aswini, age: 25}
}

2. Immutable Collections (Using const)
If we want a collection that cannot be modified after it’s created, we use the const keyword.
This makes the entire collection compile-time constant and unchangeable.

void main() {
  const list = [1, 2, 3];
  // list.add(4); ❌ Error: Unsupported operation

  const set = {10, 20, 30};
  // set.remove(10); ❌ Error

  const map = {'key': 'value'};
  // map['key2'] = 'new'; ❌ Error
}

So, const makes the collection deeply immutable — neither the structure nor the values can change.

3. Read-only Views (Using unmodifiable constructor)
Sometimes, we may want to prevent modification at runtime, but we don’t know the values at compile-time.
For that, Dart provides List.unmodifiable(), Set.unmodifiable(), and Map.unmodifiable().

void main() {
  var original = [1, 2, 3];
  var unmodifiableList = List.unmodifiable(original);

  // unmodifiableList.add(4); ❌ Throws runtime error
}

This is especially helpful when you need to expose a collection publicly but want to protect it from modification externally — I’ve used this approach in Flutter projects where I had to expose lists of UI state but ensure widgets don’t accidentally mutate them.

4. Real-world example:
In a Flutter app managing state with Provider, I stored a list of products in a model class. To ensure no widget modified it directly, I returned it as List.unmodifiable(_products). That way, any changes had to go through proper setter methods — ensuring controlled updates.

Challenges faced:
One challenge was understanding that even if you make a List unmodifiable, the objects inside can still be mutable. For example, a List.unmodifiable of custom objects can still have their internal properties changed — so it’s not “deep immutability.”

Limitations:

• const can only be used with compile-time constants.
• unmodifiable prevents structural changes but not internal object mutation.

Alternative:
If deep immutability is required, I’ve used data classes or packages like built_collection or freezed, which generate immutable models automatically — very useful for state management patterns like BLoC or Redux.

So, in summary:

Dart collections are mutable by default, but you can make them immutable using const for compile-time or unmodifiable() for runtime protection — ensuring safer and more predictable code.