Sorry for the delay in responding.
Yes, that's a fair point though I was only intending the Iif function to be
used for simple cases where the cost of evaluating both expressions is
negligible.
Such cases crop up a lot in practice and I don't think I'm the only one who
finds it tedious having to write six lines of code when a single line
suffices in most other C-family languages.
Also, knowing that both expressions will be evaluated will deter people
from passing complex expressions (including other nested IIf's, function
calls with side effects etc.) to the function which is the reason given in
the Go FAQ for not supporting the conditional operator in the first place.
So, in a sense, this is an argument for adding an Iif function as it will
enable people to write more concise code for simple cases whilst deterring
its use for complex stuff.
Alan
On Thursday, January 3, 2019 at 11:33:47 PM UTC, Milan Zamazal wrote:
>
> alanfo <alan...@gmail.com <javascript:>> writes:
>
> > Some languages which don't support the conditional operator or if/else
> > expressions have an Iif function (or similar) instead.
> >
> > If generics are added to Go, it might be worth including something like
> > this in the standard library to cut down on boilerplate for simple
> cases:
> >
> > // in a package called 'gen' say
> > func Iif(type T) (cond bool, t1, t2 T) T {
> > if cond {
> > return t1
> > }
> > return t2
> > }
> >
> > // usage
> > x := 3
> > ...
> > y := gen.Iif(x > 2, 4, 5) // T inferred to be int, assigns 4 to y
> >
> > You can, of course, do this now with interface{} but it's not type-safe
> and
> > requires a type assertion on assignment.
> >
> > A drawback is that it would require the overhead of a function call
> unless
> > the Go compiler could inline simple stuff such as this.
>
> A worse drawback is that both the alternatives are evaluated, which is a
> problem for all but very simple cases.
>
> > Alan
> >
> > On Wednesday, December 19, 2018 at 8:09:35 PM UTC, Viktor Kojouharov
> wrote:
> >>
> >> Hello,
> >>
> >> I've tried and failed at finding any previous discussion on this topic,
> so
> >> do point me to one if it exists.
> >>
> >> I'm interested to know whether it was considered (I can't imagine that
> it
> >> wasn't) for if and switch statements to be expressions instead, and if
> so,
> >> why were they ultimately left as statements. It seems to me that having
> >> them as expressions will not cause a significant change in how they are
> >> ultimately used, mostly because other languages that do support such
> >> expressions do not exhibit this behaviour either. Nor is such a change
> >> strictly backwards incompatible, since any expression is also
> technically a
> >> statement as well, via the ExpressionStmt grammar rule. Such
> expressions
> >> also cover a simple feature which a lot of people new to the language
> are
> >> looking for, and most of us have abused in other languages - ternary
> >> operators. The Go FAQ states that if-elses are clearer, if longer,
> which I
> >> definitely agree with. Yet it seems that an if expression would retain
> its
> >> readability, if not outright increase it, while allowing for terser
> >> assignments. The reason being that a chunk of repeatable code (for
> example
> >> assigning to the same variable in every logical branch) would be moved
> out
> >> of the whole block, thus highlighting the value.
> >>
> >> What if the spec defines that if all if-else blocks / all switch case
> >> clauses contain only single expression, they would be expressions
> rather
> >> than statements. How would that negatively impact the language, in a
> way
> >> that can't already be reproduced?
> >>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
