alanfo <alan.f...@gmail.com> 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.
