Wanted: better(more specific) error msgs?

[L A Walsh]

Ran into a minor error where I was testing some
dec<->hex conversion values, and later testing the display
of a unicode char.

Problem happened when I re-used a var that had earlier had the
integer property set on the variable.

declare -i a=123
...
then later
a="▯"
-bash: ▯: syntax error: operand expected (error token is "▯")
(u+25AF)

(the character didn't have a font for it, so displayed
as a square)

I'm still not sure why it is giving a syntax error when
a="t", for example doesn't (it puts a value of '0' in 'a').

But if I try:
a="z", I get the syntax error again(**)


Ideally, I'd prefer to see something like printf
prints out when it finds a non number for a decimal field:
> printf "%d" "t"
-bash: printf: t: invalid number

So why does something with the integer attrib set work somewhat
'ok' (if '0' is what you expect)...oh...

(**) - because in coming up with test cases, I had tried
assigning that 'u+25af' (▯) to 'z', oh ...just weird.
if the target has the int flag set, and what you assign is not
an integer, then you might get '0' in 'a' and no error,
or you might get a syntax error...

Um...  This behavior is a bit confusing...
It would really be better if it could say what it
was expecting, like printf.

??

I guess it's based on whether or not what you are assigning
could be a variable name -- but that sorta dovetails into something
else I'd been thinking about: being able to use more unicode
characters in var and function names, like:

$☃="snowman"

hmmm....Well, double the "want"/"need" for better error
messages, first.  Then might be nice to allow more
unicode class-"alnum" into the varname-composition class?