Losing type safety should be emphasized

[qwfy]

In the README.md, there is a line

at the price of loosing some typesafety

I think this should be emphasized with bold font, since it's very important when choosing a library.

[etaque]

Yeah, it should be explained more precisely. #83 would improve this but there is a long way to go, so I'll improve the README.

[qwfy]

Besides #83, there is another issue about type safety, namely, if you write:

field "someField"
|> string
|> nonEmpty
|> maxLength 7

in a validate function, the code compiles, but the last two checks won't have any effect, they fail silently, you have to group the three checks together and then pass it to field.

[etaque]

Okey, I've made it a bit more explicit in the README, and mentioned this issue.

[erlandsona]

Has anyone tried fixing this using Lens keys?
We use elm-review-missing-record-field-lens to code generate elm-accessors based lenses and it's been a really nice experience thus far.
I started a Form abstraction from scratch that's a dictionary keyed on the name of the lens which seems to make this sort of thing "type safe" in that Property parent field -> Model parent ensures that a Form can only be constructed and deconstructed with "keys" that operate on parent's.
What I haven't figured out is how to "Tree"-ify it to enable nested data & higher kinded types EG:
currently it works really well over

type alias Something =
    { id : Int
    , name : String
    , address : Address -- Assuming an address can be represented as a string input.
    }

What I haven't figured out yet is...

type alias SomethingWithExtraInfo =
    { id : Int
    , name : String
    , address : Address
    , emails : List Email -- Where each email would be it's own form...
    }

I feel like this is just a serialization problem but I'm starting to get a bunch of getIntProp getStrProp setIntProp setStrProp helpers and that feels sort of anti-lensy and I'm not sure quite how to make it all "fit".