gregvaughn

gregvaughn

I would expect it to return nil just as Map.get(map, key) does when the key does not exist in the map. It’s up to the caller to reject nils or not. values!/2 could raise as fetch!/2 does.

0
Post #21
lucaong

lucaong

True, but Map.get/3 allows to specify a default, which in the case of Map.values/2 (or Map.values/3 with the optional default) would have to be a single default for all the missing values, or a function to compute the default. At that point, the function starts to be substantially different from values/1 to deserve its own name.

0
Post #22
gregvaughn

gregvaughn

I think we’re going way too far off on a tangent here. I don’t care what color the bikeshed is painted :smirk: I made a throw-a-way comment about values/2 but since it’s a one-liner, I don’t plan to make a proposal to core because I don’t care enough to argue the case.

If you need to supply a default, then yeah, you’re talking about something different, and IMHO it’s probably best written explicitly in your application’s domain logic.

2
Post #23
Sanjibukai

Sanjibukai

Hello all,

I just wanted to say that seeing such encouragement to propose things (even in the core) without shaming noobs (which I personally am regarding Elixir) is very, well, encouraging!

I had some idea too.. After some practice and study, I’ll definitely try to jump on the bandwagon.

1
Post #24
sabo66

sabo66

I think ‘slice’ is better :slight_smile:

0
Post #25
benwilson512

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

I don’t think it is productive to weigh in this way 3 years later. All other uses of slice in Elixir (and a lot of other languages) use slice with index based operations.

1
Post #26
benwilson512

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe
0
Post #27
— All posts loaded —