proposal: `use_of_instead_of_from` for collections.

[kevmoo]

use_of_instead_of_from

Description

The from ctor on collections is more expensive. It does casts. If possible, use the of constructor.

Details

If the source collection has a known, compatible type statically, of should be used.

Kind

Performance.

Bad Examples

final slowList = List<int>.from(someIterableOfInt);

Good Examples

final fastList = List<int>.of(someIterableOfInt);

Discussion

This should apply to List, Set, Map and related subtypes.

See 6fae002

[mkustermann]

I'd rather just deprecate & remove the *from constructors, see #52400

[srawlins]

If the from constructors are marked @deprecated, then a "data-driven fix" (documentation link missing) can inform dart fix to convert from one constructor to another.

[lrhn]

Agree on just deprecating the old APIs.

I don't want to have lint's for every API preference. There should be a good reason to make people avoid an existing non-deprecated API.
And if the API is really bad, it should be deprecated, rather than spend resources on building a lint.

[kevmoo]

@lrhn for some nuance, I'm not saying deprecate the old API. I'm just saying don't use from if you're going (statically) from T to T.

The argument for deprecating from is pretty solid, I guess. But it's a seperate argument.

[mkustermann]

The argument for deprecating from is pretty solid, I guess. But it's a seperate argument.

@kevmoo Once it's deprecated - there's no longer a need for a new lint, is there?

It's always better to make developers use the good path by making it the only path - instead of providing many knobs/hints/... - the fact that we have a need for so many hints (see here) is IMHO a bad smell.

[kevmoo]

@lrhn @mkustermann – then let's do it. What's the recommended alternative for folks using from if they can't use of?

Iterable.cast<T>?

[lrhn]

Literal. [for (var v in iterable) v as T].
That makes the cast explicit.
(And instead of List.of, just use [... iterable], it's even shorter than the constructor.)

Using List.of(iterable.cast<T>()) is also an option.

[munificent]

I was going to suggest we keep List.from() since it's the only way I could think of to create a list:

1. From another list.
2. With a different element type (by casting each element).
3. That is non-growable.

But I realize that in the rare cases where you want all three of these, you could always use List.filled() or List.generate().

So +1 for getting rid of List.from().

[natebosch]

it's the only way I could think of to create a list:

I think it's more clear to use List<Foo>.of(iterable.cast()) than List.filled or List.generate for this case.

+1 for deprecating .from(). There is a lot of usage, but from a skim I don't see any cases that would be harmed by a refactor.

[rakudrama]

I would also like to see the .unmodifiable constructors be more strongly typed.
In the pattern of constructor names that our users have come to expect, there is no constructor for ?:

.from : .of :: .unmodifiable : ?

If we are deprecating from, can we 'just' make .unmodifiable stronger rather than invent a new clunky name for what we really want?

[lrhn]

I'd love to make those better typed too. It's breaking. Don't know how much. (Will check!)

Seems Set.unmodifiable is already typed well, it's only List and Map that needs it (you can see which types are older).