Add back the typed representation of the Link header

[jplatte]

This is exactly #67 except it uses the latest version of language-tags and is rebased.

edit: Now one extra commit of my own, as commit authorship shows.

Closes #67.

[jplatte]

ping @seanmonstar

[seanmonstar]

They're not part of the diff, so I can't comment at the specific line, but I think a few parts of the public API should be adjusted, so they make less promises about internals. Such as:

• Link::new(Vec<_>) - Perhaps it should be new(), taking no arguments, to start with an empty link header.
• Link::values() -> &[LinkValue] - This implies we have a contiguous slice of values, but we could conceivably place them in a different data structure (a vecdeque, or a hashmap), or even eagerly serialize them. I'd probably change this to return an impl Iterator. Maybe some of the other types name this as iter? I can't recall.

[jplatte]

Sounds good! I added a FromIterator implementation as a less "biased" version of the previous new, so it's still convenient to construct a Link from a list of LinkValues.

I found no other occurrences of a values method but many iters, so I updated that name.

[seanmonstar]

Besides the couple of comments which should be quick to fix, a final check would be good: is there any type, or method, which is exposing it's internal structure? Any forwards-compatibility hazards that if we needed to change, would need a breaking change?

[seanmonstar]

Should the default iterator be cloning the values? Why not give references, and a user can clone if they need to?

[jplatte]

Maybe so the internal storage can be changed to something that isn't a container of LinkValues? Happy to change this.

[jplatte]

Do you want it changed?

[seanmonstar]

I've tried scrolling through to find the answer, but failed so far. We don't expose this dependency, right?

[jplatte]

We are, actually. LinkValue::href_lang returns Option<&[LanguageTag]>, and LinkValue::push_href_lang has the parameter language_tag: LanguageTag.

[jplatte]

So you want that to change before merging?

[seanmonstar]

I'd rather not expose this dependency publicly, at least that's my default feeling.

[jplatte]

Personally I feel like it shouldn't be such a big deal for headers, as opposed to headers-core. But I'll look into how complex it would be to remove it from public API / what the consequences would be exactly.

[jplatte]

So the main reason I would like to not change the code here is that it allows push_href_lang to be infallible. If language-tags was required to be removed from public API, that would mean parsing the language tag provided by the user in that function. Please let me know whether you agree or not and I'll update the PR accordingly.