[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Possible RFE? allowing array-initializer lists to be addressed like arra

From: L. A. Walsh
Subject: Possible RFE? allowing array-initializer lists to be addressed like arrays
Date: Sun, 10 Jul 2016 18:10:12 -0700
User-agent: Thunderbird

I was wanting to print, a true|false type text
based on a boolean.

What first came to mine was using an array holding the
false & true values (in that order) and indexed by the
((value)) as 0=false, !0=true since arithmetic evals
yield true or false depending on whether the expression
evaluates to non-zero or zero, respectively.

Then I wondered if there was a way to do that w/o arrays,
and wondered about this possible syntax:

 printf "%s\n" ${(yes no)[(($expr))]}

I know it doesn't currently work that way, but is there
any syntax-confusion-related reason why it couldn't?

Currently, input:

 unset a
 a=(yes no)
 #for y/n conditions:
 declare -i y=0 n=1
 printf "%s, %s\n" "${a[((y))]}" "${a[((n))]}"


  yes, no

The extra (()) are really superfluous if you ensure the value
in [] evals to <0|1> in the opposite sense that it would in (()),
or just reversing the list order of the T/F values in the array:

 unset a
 a=(no yes); declare -i y=0 n=1
 printf "%s, %s\n" "${a[!y]}" "${a[!n]}"
 yes, no

Would there be a syntax conflict in allowing an array initializer list
in-place of 'a'?  like (53 chars):

 printf "%s, %s\n" "${(no yes)[!y]}" "${(no yes)[!n]}"

Obviously, the whole thing could be wrapped in a sub, but
that would incur a process fork w/every yes/no as well as
the array assignment (to be safe), i.e. (103 chars):

 yn() { declare -a ny=(no yes); printf "%s" "${ny[$# && !$1]}"; }
 printf "%s, %s\n" "$(yn $y)" "$(yn $n)"

Anyway -- was mostly interested in whether or not something like that
might be possible to add (or allow) as a feature enhancement?

Since the list-form generates a syntax error, I can't see allowing it
to be a compatibility problem in any existing, working scripts -- which
would seem to "ok" it from a syntax POV.  Would it be too hard to
implement given that the array-initializer syntax seems to be limited
to being an initialization-value for an array?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]