Sure, that's a design decision. How useful does something have to be before it's hard-coded. Matter of judgement. Tho I'm vocal with my opinion, at the end of the day it's not my call, nor should it be. However a guy like you is so conformed to the status quo -- nuts, you built it -- that you no longer 'see' the defects as defects (this presuming I'll right when in fact I am often wrong). Where a guy like me can be useful is in providing a fresh view of things. I advocate for spelling reform. Folks who's spelling is perfect say that spelling reform isn't needed.
It's the other way around. The function gave you what you want, so there's nothing for a built-in to the shell to do.
If NO function could give you what you wanted, that's a different
question. E.g., it's a valid point that a parameter declared with
"typeset -E" could be more accurately described by $parameters /
${(t)var}, or that justification width could be more obviously
obtainable than just "typeset +m",
That's another interesting question. IMHO core functionality is not
-- or not hugely -- concerned with appearance -- the individual
tarts things up as he sees fit -- but *complete* information is a
core function. OTOH, a justification option would be very nice --
saves me the trouble. But, for example, I'd put spaces around the
equal signs cuz it then breaks the output into logical words and
thus makes it very much easier to, say, columnize the display.
or even that the documentation
could do a better job of relating ${(t)var} to the options of
"typeset" (I've submitted a patch for that last, incidentally).
In that case my opinion is that the 'Parameters' section of the
manual should tell the whole story vs. the information being
attached to individual commands, since there are several commands
-- not to mention ${(t)...} -- that have a duplicated
use/reference to the attributes; so they should all refer back to
Mother. IOW, the fact that parameters have attributes is a
fundamental feature of the shell irrespective of any particular
command, not an incidental collection of details pertaining to
this command or that command. That could be said better.
In the crudest, outline form, add something like the 'help' for my function:
A parameter has a name, a value, and a number of attributes. A name may be any sequence of alphanumeric characters and underscores, or the single characters ‘*’, ‘@’, ‘#’, ‘?’, ‘-’, ‘$’, or ‘!’. A parameter whose name begins with an alphanumeric or underscore is also referred to as a variable.
The attributes of a parameter determine the type of its
value, often
referred to as the parameter type or variable type, and also
control
other processing that may be applied to the value when it is
referenced.
The value type may be a scalar (a string, an integer, or
a floating
point number), an array (indexed numerically), or an associative
array (an unordered set of name-value pairs, indexed by name, also
referred to as a hash).
Here's a complete list of the types and the attributes ( with their single-letter designations as used in various commands [ maybe not but .... ] ):
TYPES:
S: An ordinary scalar (not an integer or float).
I: An integer.
F: A float ('typeset -F:' decimal display or 'typeset -E':
scientific display).
A: A normal array.
H: An associative array or 'association' or 'hash' (always
'hideval' as well).
ATTRIBUTES:
e: The variable has been exported to the enironment and is thus
persistent within that terminal -- it will be inherited by
subshells.
l: The variable is local to the running function.
t: The variable is 'tied' to another variable.
s: The variable is special to the shell.
r: The variable is read-only (this often goes with 'special').
v: 'hideval': the value of the variable will be hidden -- there
are things we really don't want to see, like lists of color
codes. This tends to go with 'special' and 'hide'.
h: Hide: Used with 'special' ??
u: Unique: ??
?: Undefined: For autoloaded parameters not yet loaded (whatever
that means).
These types and attributes will now be discussed in detail:
... back to text.
BTW, that section of the manual is very well written, almost literate, and technical writing hardly ever is, tho I do wish it was complete.
BTW am I mistaken that 'hideval' is not discussed anywhere?