2 ms·
Sorry, I added more issues as I copied the corresponding snippets from the RFC. Your suggestion is to not use a regexp, but is less valid, and likely less effi
by supermatt 5y ago
Sorry, I added more issues as I copied the corresponding snippets from the RFC.
Your suggestion is to not use a regexp, but is less valid, and likely less efficient than a regexp that checks for the presence of an @ anywhere than at the start.
- RajT88 5y ago> Your suggestion is to not use a regexp, but is less valid, and likely less efficient than a regexp that checks for the presence of an @ anywhere than at the start. This is actually the whole point of what I wrote. Making the maintenance of the code low-effort, and having it be more permissive (i.e. less valid) and relying for the corner cases to be taken care of via email bounce. See: explainer on "Now you have 2 problems" https://arstechnica.com/information-technology/2014/05/what-is-meant-by-now-you-have-two-problems/ https://arstechnica.com/information-technology/2014/05/what-... If you read this whole comment thread you can see where this leads: increasingly complex regex in order to handle all the corner cases. Forget the corner cases, just make it "good enough" and relegate those corner cases to email bounce. Now - I don't have a case study to prove that this way of going about it is more valid than the strict regex validation you're suggesting. But I wanted to represent it as a middle ground between "just rely on email bounce" and "write a big long regex".
- supermatt 5y agoI like the first comment on that article: Some people, when trying to explain something, think "I know, I'll use a Jamie Zawinski quote." Now they have two things to explain.