I assume this would be a fallback - so Foo <email> (Bar) would parse as {Name: "Foo", Address: "email"}. Or do you have something else in mind?

Are there any cases where the name is missing and the comment is used for a different purpose?

I am also wondering if it would be useful to somehow make this difference visible to the developer. Otherwise, Foo <email> and <email> (Foo) would seem the same when parsing.

I assume this would be a fallback - so Foo (Bar) would parse as {Name: "Foo", Address: "email"}.

Correct

Are there any cases where the name is missing and the comment is used for a different purpose?

I haven’t seen any so far, but of course that doesn’t mean such cases don’t exist.

I am also wondering if it would be useful to somehow make this difference visible to the developer. Otherwise, Foo and (Foo) would seem the same when parsing.

I’m not sure why a developer would need to concern themselves with this subtle detail of email parsing? :)

My knowledge of email address formats is limited, so I was simply trying to clarify the proposal a bit and see if there would be any noticeable disadvantages to accepting it.

It also seems like putting display names in the comments has been discouraged since 1982:

https://wordtothewise.com/2014/12/friendly-email-addresses/:

Never do this. The text in parentheses isn’t really a display name at all, rather it’s a human readable comment. Many MUAs will display that comment as though it were the display name, but it’s not been the right way to include a display name at least since RFC 822 was released in 1982.

RFC: http://tools.wordtothewise.com/rfc/822

Nevertheless, if this practice is still common, it seems okay to me to support it as a fallback.

Yep, I’m aware of the RFC :). We can of course also file bugs against mutt, neomutt, gnus and debbugs to use a more modern addr-spec, but that won’t fix the messages in my archives, which is why I’m starting to work on this end of the issue first.

That makes sense. I guess the only drawback of doing it would be that we'd be encouraging the bad behavior - but it's clearly too late for that :)

The point about being able to use email archives is useful, though. golang.org/s/owners just lists @bradfitz as maintainer - any thoughts, Brad? I realise the package is frozen, but this would not increase or change its API.

Wouldn't be dangerous to put in Address.Name something that is sometimes used as the display name?

Even if ( ... ) is used for the name, say, 90% of the time, we would be returning a completely bogus value in Address.Name in the remaining 10%.

I mean, it would be pretty reasonable to assume that Address.Name != "" implies that the parsed address has form display-name <addr>, has a name in it, and I can retrieve that name at Address.Name.

This is true now, but if we start parsing

"foo@bar.com (comment)"

as

Address{Name: "comment", Address: "foo@bar.com"}

that assumption breaks. Address.Name is not empty, even if we just parsed an email address with no name in it.

The point is that when you write NAME <ADDR>, NAME can only be display-name. The spec requires this, if I read it correctly. So, putting NAME into Address.Name is a safe bet. Using Address.Name to store a (...) comment, not so much.

Wouldn't be dangerous to put in Address.Name something that is sometimes used as the display name?

RFC822 states “Many MUAs will display that comment as though it were the display name”.

I understand this as: one should expect comments in the From header to commonly be interpreted as display name, provided no actual display name is present in the addr-spec.

I can’t quite see any danger in implementing what an RFC states is common practice, and only affects a fallback code path. Even in the unlikely event that this case actually exists anywhere (do you have any real-world examples of this edge case?), I would maintain that treating such a comment as display name is actually sensible — most likely it will identify the author of the message.

If, when present, the ( ... ) comment is pretty much always intended to be used as display-name, I guess it could be reasonable to implement your proposed change. I don't have any hard data about how frequently that assumption does not hold in the wild.

Per @golang/proposal-review, if there's just one comment after the address, sure, let's make it the Name. CL welcome for Go 1.11.

Thanks! I’ll try to send a CL tomorrow.

Change https://golang.org/cl/77474 mentions this issue: net/mail: treat comment in address as display name

It looks like handling comments at all is new in Go 1.10. Given that, we might as well fix this now and avoid having a release that handles but drops comments.