call_statement: should only be able to call a function that yields void?

[dneto0]

That can catch some programming errors.

If you really want to call a value-producing function at statement level, only for its side effects, then you can always capture its result in a const-declaration.

  const toss_it: T = CallForSideEffects();

Or

  const _ := CallForSideEffects();  // if we have type deduction

  _  := CallForSideEffects();  // even more aggressive throwaway with type deduction

  // Invent a void-constructor  explicitly for this purpose. 
  // It's a sink for values, producing void.
  void(CallForSideEffects());  

[dneto0]

#1412 is a somewhat related grammar change.

[kvark]

Played with this in Naga, and I'm strongly in favor of this. 🚀

[dneto0]

I propose adding a void constructor builtin function:

    void(sink:T) -> void;

A call to the void function can appear as a statement in a function body. It evaluates its argument, and yields no value.

Also, add the rule that when a statement is a function calll, that function must have void return type.

---

edited to add the new validation rule

[kvark]

Let's not mix this into the void(sink) suggestion, please file it separately?
I don't see why it's needed. Users can always just declare a constant to get a result of anything.

[ben-clayton]

I don't see why it's needed. Users can always just declare a constant to get a result of anything.

It's not uncommon to have compilers warn about unused variables. (void) expr is the typical way to tell a C++ compiler that an expression is intentionally unused.

[kvark]

Ok, we can add void(sink:T) once we agree on the warnings. It doesn't require void type anyway.

Btw, since #1413 (comment) was written I've remade the support for function calling in Naga, and now this proposal doesn't give us anything at all. We are now totally cool to support:

my_function();

[dneto0]

Let's not mix this into the void(sink) suggestion, please file it separately?

I filed #1499 for the void constructor idea.

[dneto0]

Discussed 2021-03-09

[dneto0]

Hey @jdashg you marked this as resolved-needs spec. But reading the notes, I'm not clear there was consensus to make this an error. I don't know what the consensus is.

[kvark]

I read the consensus as:

• don't allow the statement calls into functions with return types
• follow-up with the ignore function at some point

[kdashg]

I think this is closed by #2138.