[Issue 18124] std.regex.RegexMatch's front property is under-documented

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=18124

--- Comment #5 from Neia Neutuladh <dhasenan at gmail.com> ---
(In reply to Seb from comment #1)
> A good improvement, however, could be to improve Ddoc or documentation, s.t.
> it helps the reader more what `auto` could be mean and whats capabilities
> one can expect from it.

std.regex.Captures has fourteen public members. You think it is better to
document its public members in std.regex.match *and* std.regex.matchFirst than
to just point to the types? That's an interesting perspective.

(In reply to Steven Schveighoffer from comment #4)
> what auto does allow is changing the NAME of the result

Aliases also allow changing the name of the type even if you use concrete
types. It's just that you need a deprecation cycle.

So if you think there's a strong risk you *absolutely must* have another struct
in std.regex named Captures in the next Phobos release, sure, keep the existing
one private and use `auto` return types. If you merely think you might get a
better name for it in the near future, you can change it then and add a
deprecated alias for the existing name. Or, more likely, you'll be told that
changing the name is bikeshedding and that you should keep it as is -- which is
generally a good idea.

A slightly more salient change is that you might move a type so it's more
widely accessible. Perhaps a year from now we'll want to use a Captures object
for a std.string.find function. A public import if the name is kept the same,
or an alias if it is not, functions just as well as using an auto return type.

The only change that it possibly lets you do is change between several existing
types instead of committing to the same type for each.

In this case, the implementation for std.regex.matchFirst is a manually inlined
version of
  return matchMany(args).front;

That makes it unlikely that the types will become incompatible.

> Just another tip: you may want to avoid taking unnecessary offense at
> innocuous things for no reason. Most people in our organization are friendly
> and cheerful people, including Seb. Thanks! ;)

In point of fact, what I experienced was _anger_, not offense. Detached
professionalism doesn't give anger a target.

By reiterating a behavior I just complained about in response to me complaining
about it, it looks like you are trying to deliberately antagonize me. This is a
concept that most of my cohort had grasped by second grade. I believe you've
been in the D community as long as me, which means you should be an adult, or
near enough.

Do you have some sort of social disability that makes it difficult for you to
learn things like this? If so, I'll try to take that into account in our future
interactions.

--