Json.Decode should expose "key" as a non-infix name for (:=)

[ThomasWeiser]

NoRedInk/elm-decode-pipeline postulates the abstention of infix operators, IMHO for good reasons, at least in library APIs.

Json.Decode exports the infix operator := without a non-infix name. I propose to give it also a reasonable non-infix name. Can't make up for a good one at the moment, but think about something like at1 key.

Example, using the infix operator:

import Json.Decode as JD exposing ((:=))

decodeName : JD.Decoder String
decodeName = "name" := JD.string

Evading infix operators currently forces to use at with a one-member list:

import Json.Decode as JD

decodeName = JD.at ["name"] JD.string

Proposal (edited):

decodeName = JD.key "name" JD.string

[jvoigtlaender]

How about

decodeName = JD.child "name" JD.string

or something like that? Also possible: field.

[jvoigtlaender]

How about

decodeName = JD.child "name" JD.string

or something like that? Also possible: field.

[ThomasWeiser]

Musing about the name: Official JSON docs speak of name/value pairs, but name is not a nice name :) Actually, the most used term (beside name) in JSON land seems to be key. This is also the idiom used in Elm's Dict and it already appears as Json.Decode.keyValuePairs.

So I propose: Json.Decode.key as in:

import Json.Decode as JD

decodeName : JD.Decoder String
decodeName = JD.key "name" JD.string

[ThomasWeiser]

Musing about the name: Official JSON docs speak of name/value pairs, but name is not a nice name :) Actually, the most used term (beside name) in JSON land seems to be key. This is also the idiom used in Elm's Dict and it already appears as Json.Decode.keyValuePairs.

So I propose: Json.Decode.key as in:

import Json.Decode as JD

decodeName : JD.Decoder String
decodeName = JD.key "name" JD.string

[evancz]

I agree that the API should be changed to be more in line with more recent libraries informed by usage, but I do not want to track API suggestions here.

[evancz]

I agree that the API should be changed to be more in line with more recent libraries informed by usage, but I do not want to track API suggestions here.