Detect Non-Mutating Call Statements to Pure Functions in D

Question

I believe D has the potential to add yet another cool feature to its suite of compilers, namely the power to disallow non-side-effect calls to pure functions.

For example

auto s = "a";
toStringz(a);

should error just like

a == "";

currently errors in DMD as

Error: == has no effect in expression (s == "")

Such as feature would prevent the programmer from accidentally calling non-muting algorithms when he expects it to have in-place (mutating) semantics. This without having to explicitly tag functions with attributes such as GCC's __attribute((warn_unused_result)) alongside __attribute((const)).

Is such a feature on the todo list for DMD?

I am all about learning new cool stuff, but I can't quite see the *question* here. — amon, Mar 02 '13 at 11:39

score 3 · Accepted Answer · answered Mar 02 '13 at 11:43

3

There is no official TODO-list for DMD. Its development is mostly based on volunteers work and while some enhancement requests get "preapproved" tag in bugzilla, it does not tell anything about terms when this feature can be implemented or will it be implemented at all.

Given there are a lot of much more serious issues to address right now, I hardly can expect something that minor implemented in nearby years.

Also your question actually looks like proposal and is better suited to official DMD/Phobos bugzilla: http://d.puremagic.com/issues/

answered Mar 02 '13 at 11:43

Mihails Strasuns

3,783
1
18
21

There's already a discussion on this topic here http://d.puremagic.com/issues/show_bug.cgi?id=3882 – Nordlöw Mar 02 '13 at 14:43
Well, I am totally not surprised bearophile has already got this :) – Mihails Strasuns Mar 02 '13 at 16:48

score 0 · Answer 2 · answered Mar 02 '13 at 16:39

0

The problem is D's heavy uses of templates. You don't always have control on either the template or it's arguments. For example:

class Foo{
    /*...*/
    pure int foo(){
        /*...*/
    }
    /*...*/
}

void bar(T)(T arg){
    /*...*/
    arg.foo();
    /*...*/
}

Now you can't call bar with a Foo arguments. This can be fixed(hacked) by either removing foo's pureness(which might break the code and/or harm performance) or changing bar to store foo()'s result in a variable(which is also bad, because it never uses that value and because foo's return type might be void or even worse - a struct with a destructor(which it's call will be postponed to the end of bar's execution). And ofcourse - that is only possible if you can change Foo or bar...

answered Mar 02 '13 at 16:39

Idan Arye

12,402
5
49
68

That is arguable. If template expects function call to do something and in provided type this function is pure, that smells like error and template should be fixed itself. Returning struct with destructor is not "no effect" expression and is irrelevant. – Mihails Strasuns Mar 02 '13 at 16:47
The point is that the creator of `bar` might not know that the `foo` method of it's argument is pure, or that `Foo` even exists. It might need to work with other classes beside `Foo`, that have a `foo` method with desired side-effects, and it's running `foo` whenever it has side effects or not - because it works anyways, it doesn't matter, and not running it will break `bar` in the case that `foo` has side effects. – Idan Arye Mar 03 '13 at 00:50
And my point is that bar is broken by design if it uses some unknown function without storing result and caring if it is pure. Currently to handle this right you need plenty of static constraints, this enhancement will take care of it for you. I have yet to see example of code gen that results in functions calls without caring why it calls them. – Mihails Strasuns Mar 03 '13 at 11:06

Detect Non-Mutating Call Statements to Pure Functions in D

2 Answers2