@strict

[bearophile]

Pure functions are nice because a smart compiler can sometimes perform some optimizations with them that aren't possible with normal functions. But for me their main advantage is that they help avoid some bugs, because they can't modify global state nor change their behaviour on its base (we can ignore memory overflow, and maybe even exceptions). My Python/Delphi programs that are mostly composed of nearly-pure functions are often the ones with the lower bug count.

I have seen that's true in OOP too: methods that are static (and don't use static attributes, they are pure methods, essentially) are often the less buggy ones. So I use static methods where I can, every time I can write a method that uses just the input arguments.

But programming in D with just pure functions is not always handy, and in OOP I sometimes must alter instance attributes, so they can't be pure. And sometimes using a variable that's not an argument of the function produces a little faster code/function.

So in D I can think of something intermediate between a pure function and a normal function/method, something that keeps code flexible but with a lower bug count. For this I can think about an attribute @strict that can be used on a free function, a nested function, an object method, and even a class (it means all it methods are @strict). Even @strict modules are possible (it means all callables inside it are @strict). (If I will ever design a new imperative language this will be the default behaviour. Using outer names randomly as in C/Java/C#/D is bad. Python3 partially avoids this trap with its "outer" and "nonlocal" statements).

@strict denotes a normal function/method, where all the names (variable) it uses inside are written down in an explicit way. Some of such names are normal function arguments, the other names can be global variables, variables from an outer function, instance attributes, static class attributes, enums.

// inside here types are optional
@strict(in int y, in z, out k, inout w) int foo(int x) {
  // ... code
}

This function/method "foo" takes int "x" as argument. Foo can't use outer/instance/static names beside "y","z","w","k" ("y" and "z" can't be written inside foo, "k" can't be read inside foo, and "w" is read/write by foo).

Some alternative syntaxes, a better syntax can be invented:

@strict_in(int y, z)
@strict_out(k)
@strict_inout(w)
int foo(int x) {
  // ... code
}


@strict int foo(int x) {
  @in int y;
  @in z; // types are optional
  @out k;
  @inout w;
  // ... code
}


@strict [in int y, in z, out k, inout w]
int foo(int x) {
  // ... code
}


@in int y;
@in z;
@out k;
@inout w;
@strict int foo(int x) {
  // ... code
}


@strict int foo(int x) {
  @strict_in int y;
  @strictl_in z;
  @strict_out k;
  @strict_inout w;
  // ... code
}


@strict int foo(int x) {
  @nonlocal_in int y
  @nonlocal_in z
  @nonlocal_out k
  @nonlocal_inout w
  // ... code
}


Why it's useful: system theory says that improving the separation of subsystems you reduce unwanted side effects, improving the reliability of the whole system.

That's why D modules too must produce a better isolation: as in Python "import bar;" has to import only the "bar" name in the namespace, so for example there are no new global variables and no surprises. This is a small change to the D module system that will improve D code. A simple syntax like "import foo: *;" can be used for the current (to be discouraged) behaviour.

Bye,
bearophile