Should we drop `inline if` syntax?

[nicolasstucki]

With the scala.compiletime.requireConst in #9764 the inline if concept becomes redundant.
const trivially subsume all use-cases of inline if with no extra syntactic overhead

- inline if n == 0 then ... 
- else inline if n % 2 == 0 then ...
+ if requireConst(n == 0) then ...
+ else if requireConst(n % 2 == 0) then ...
else

Using const has also the advantage of linking to some documentation in the IDE and is more consistent with the other compile-time operations such as summonInline.

Advantages

• Less special syntax
• Most inline operations will be found by looking in scala.compiletime
• Easier to read else ifs

Disadvantages

• Legacy code

[liufengyun]

What is the difference between if const(n % 2 == 0) and if const(n) % 2 == 0?

[sjrd]

@liufengyun Supposedly, with a good enough constant folder, it could be different is n is in fact 2 * x, with x non-constant. const(n) % 2 == 0 would report an error because 2 * x is not constant, but const(n % 2 == 0) could pass through because (2 * x) % 2 might be folded as 0.

That specific example is not very realistic, but there might other cases where it makes a real difference in practice.

[nicolasstucki]

Another difference between the two is the error message. const(n % 2 == 0) will say that n % 2 == 0 is not a constant and const(n) % 2 == 0 will say that n is not a costant.

[liufengyun]

I find I have a little problem reading if const(n % 2 == 0): it seems to suggest that as long as n % 2 == 0 is a constant, then do something. The expression if const(n) % 2 == 0 reads more natural to me.

[nicolasstucki]

You can write the one that you prefer, there should not be too much difference in practice. The first one will also check that constant folding worked as expected. The point here is that either one will subsume the inline if feature.

[nicolasstucki]

I updated const to requireConst as in #9764

[LPTK]

This seems to go in the wrong direction of emphasizing the mechanism rather than the intention. With a similar reasoning, we could also argue that object is unnecessary (could be lazy vals), inline def is unnecessary (could be macros), given type classes and parameters are unnecessary (could be implicits), etc.

Users new to Scala may not understand that if requireConst(...) is guaranteed to be simplified, whereas that fact is self-evident with the inline if syntax.

We have the inline keyword, so why not use it? And the feature is already implemented.

[nicolasstucki]

Inline is only a soft keyword. For example val inline = ... is a valid name and inline if inline then .... is a valid condition. This makes may make it a bit harder for users where inline is a keyword and where it is not. It also complicates a bit the syntax highlighting rules which have to include some heuristics.

If you which to have a clear differentiation between intent and mechanism, then writing the same a macro would be better. And removing inline if could be considered as removing a crutch that only achieves the intended behavior partially.

[nicolasstucki]

In a macro we would have the following code where it is much clearer which parts of the code are executed at compiletime.

if n == 0 then '{ ... }
else if n % 2 == 0 then '{ ... }
else '{ ... }

[nicolasstucki]

Actually the intent of an inline if is to find conditions that did not get constant folded to a constant. We are using inline if as a coarse grained mechanism to detect these cases. The intent vs mechanism argument actually supports the use of requiredConst.

[nicolasstucki]

We decided to not change this for now.