Skip to content

Conversation

lexmag
Copy link
Member

@lexmag lexmag commented Dec 12, 2015

Closes #4071.

{^key, value} -> {:ok, value}
false -> :error
end
Keyword.fetch(list, key)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we really want to "inline" this call since we already use Keyword.get_and_update below and I don't think Access calls are meant to be used with big lists (mostly small options, params, etc.) and will be called intensively.

@lexmag lexmag force-pushed the non-keywords-access branch from 3945144 to f440374 Compare December 12, 2015 13:25
lexmag added a commit that referenced this pull request Dec 12, 2015
Raise when Access syntax used on non-keywords
@lexmag lexmag merged commit 5e15f2e into elixir-lang:master Dec 12, 2015
@lexmag lexmag deleted the non-keywords-access branch December 12, 2015 13:34
@josevalim
Copy link
Member

Should we raise a nice error message like we did in 1.0 that said the
access protocol is only available to keywords? Much clearer than a function
clause error.

José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Director of R&D

@lexmag
Copy link
Member Author

lexmag commented Dec 12, 2015

I think we should make it nicer because of the call transformation [:key] –> Access.fetch what could be unclear for newcomers, and there is another case which we should consider:

iex> [{:foo, 1, 1}][:foo]
** (CaseClauseError) no case clause matching: {:foo, 1, 1}
    (elixir) lib/access.ex:57: Access.fetch/2

@lexmag
Copy link
Member Author

lexmag commented Dec 12, 2015

And it nicely works together with the 1. from #4070.

@josevalim
Copy link
Member

Yes, let's improve all those cases. #4070 will be at compile time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants