const constraint for function arguments about c3c HOT 6 CLOSED

It works differently in C3, but covers the same thing.

1. "Const" is only used on global declarations, and does not have a memory location. It's similar to "#define"
2. All type qualifiers from C, including const is gone.
3. Declare a guarantee to have a parameter unchanged by using @ensure const(foo) in the docs.
4. If a function annotates a parameter as @ensure const but it's passed to a function that doesn't ensure const, then a warning/error is issued. This error may be suppressed as there are occasions where the annotation might be missing but the caller is sure that it is unchanged. In this case, altering the variable might lead to the variable having stale data when later used.

from c3c.

Reply to #15 (comment):

The major difference that I see is that:

1. @ensure const(foo) is part of function definition, written in that single place. It is more/less C's const alternative syntax.

2. OTOH, the "!argument" could be used at multiple places, whenever the caller wanted to be sure of immutability. Function definition itself doesn't claim anything about its constness.

   Documentation generator/IDE could still discover and document the very strong property "function doesn't modify this parameter under any circumstances". This property is what C's const could have been, if only there were no type casts and const was transitive.

I argue, that the method (1) brings only little benefit, but marking code at the caller place - method (2) - gives the code reader more valuable hints.

from c3c.

I agree that marking at the call site is a more powerful thing, but in the end the code can't feel too busy either. Sigils in C3 are used to indicate variable types and in an integral part of the name. And obviously using "!" is out of the question since that brings the code far away from C. This needs to feel like an evolution of C, not a revolution syntactically.

Let's say we'd consider using const(var) as call place annotation, that is:

int x = 0;
foo(const(&x));

There are a few things to consider:

1. Verbosity
2. There are actually 3 different things that can happen to x: "in", "out", "inout". "in": argument will only be read, "out": argument will be written to, but never read, "inout" argument will be both read from an written to. Const/not const actually only covers 2 cases. Consequently if one would explore this it is still insufficient.
3. I deliberately want to avoid infecting everything with const annotations, and that's what happens in C, sort of a virus.
4. Consider the situation where you use a method function. bar.doSomething(); here bar may or may not be modified. Adding some annotation here to indicate things is getting painful.

BTW @ensure const(foo) is transitive unlike C's const.

from c3c.

Reply to #15 (comment):

int x = 0;
foo(const(&x));

If most of these checks are concentrated in tests (which is what I suspect), then this would be good enough. Possibly even better than "!", as it directs attention to what the test is supposed to be about.

With this annotation, do you rely on what the functions claims (@ensure const(foo)) or do you do verify (or plan to verify) it with your own memory check? Because if I annotate certain piece of code, I want it to be true right here, not necessarily over there or even everywhere.

The above example gave me one idea: this kind of annotations (which I pressume would use runtime checking) could be restricted to the tests, to top level function calls in tests.

This would have following advantages:

1. data used in tests are under much stricter control. It cannot happen, that the check would suddenly need to compare 1 GB again another 1 GB. If it happens, then you wrote a bad test.
2. these checks would be restricted to test mode(s), when one doesn't care that much about performance. Normal debug mode w/o tests won't be in risk of uncontrolled slowdown.

"in", "out", "inout" things:

If function can have multiple return values, the "out" could be eliminated for good.

bar.doSomething();

would be annotated the same way:

!bar.doSomething();

or

const(bar.doSomething());

Once developer internalizes that ! / const means immutable, it feels natural.

from c3c.

I find it a bit disjointed to have all these discussions here at github issues. This is much more natural to discuss on the Discord, so could I perhaps ask if we could move the discussion there instead?

from c3c.

Please file each as an issue on c3docs

from c3c.