`const` attached to vararg formal argument

Users
1

Hello,

In the following code, I am receiving multiple arguments as a tuple (args) and simply printing it again. Inside the routine, I have also tried modifying the 1st element of the tuple (here assuming it as int). (ATO)

proc myPrintln(args...) // (*1)
// proc myPrintln(const args...) // (*2)
{
  writeln("args.type     = ", args.type:string);
  writeln("args (before) = ", args);

  args[0] *= 10;  // modify tuple (just for test)

  writeln("args (after) = ", args);
}

myPrintln(1, 2.3, "four");

The result is

args.type     = (int(64),real(64),string)
args (before) = (1, 2.3, four)
args (after) = (10, 2.3, four)

which seems reasonable if I assume that the args (= a tuple) is created locally and it is modifiable. On the other hand, when I attach const on the formal argument, I still get the same result (i.e., args[1] = 10). Is this an expected behavior, or am I doing something weird...? (FYI, I have no real "use case" for this combination (const + vararg), but just happened to try it. Also, I am not sure whether it is valid to attach const for the vararg argument.)

2

Hi Takeshi —

This looks like a bug to me. First, because (as you guessed), attaching a const to any formal argument ought to result in an error when you try to modify it. Secondly, because I believe that the default intent for each of a tuple's components is intended to be the same as the default intent for that component's type. Since the default intent of int is const and varargs are implemented using tuples, I'd expect that a[0] should similarly be const and not be modifiable.

It looks to me that this is probably specific to varargs arguments since, if I rewrite the routine to take a tuple argument rather than a varargs argument, it behaves as I'd expect; and since varargs are meant to be implemented as tuples, I'd expect the two to be equivalent.

Here's one copy of my tuple version, which infers that the type of the argument is a tuple [ATO]:

// proc myPrintln(args)       // (*1) Complains about modifying a const, as expected
// proc myPrintln(const args) // (*2) Same
// proc myPrintln(ref args)   // (*3) Complains about sending non-lvalues to a 'ref' argument
proc myPrintln(in args)       // (*4) Works, as expected
{
  writeln("args.type     = ", args.type:string);
  writeln("args (before) = ", args);

  args[0] *= 10;  // modify tuple

  writeln("args (after) = ", args);
}

myPrintln((1, 2.3, "four"));

And here's a link to a second version that uses an explicitly typed tuple and gets the same result.

I looked and did not find an existing github issue for this, so would like to be sure we capture it as one. Would you be willing to write that up?

-Brad

3

Thanks very much for your explanation and additional tests! I will file an issue on the Github page. (I guess that the combination of const + vararg might be rather rare to be used in real codes, but anyway...)
-- Takeshi

4

Hi Takeshi —

Thanks for your willingness to file the issue.

I guess that the combination of const + vararg might be rather rare to be used in real codes

Perhaps, but I think the default intent is very common, and the compiler should be preventing people from violating const-ness in that case, requiring an explicit ref or in.

Thanks again,
-Brad

1 Like