5 ms·

Does it enforce these attributes or are they just a promise by the code author?

dmitrygr 7y ago
They are a promise and that is precisely what makes them powerful. It gives GCC info it might not be able to derive, but you know to be true. You can even promise a func is pure without even implementing it in the same translation unit! That produces lots of improvement. See these two godbolt links: https://godbolt.org/z/v2zqJI https://godbolt.org/z/v2zqJI https://godbolt.org/z/kk3Q3T https://godbolt.org/z/kk3Q3T
- einpoklum 7y ago
  > You can even promise a func is pure without even implementing it in the same translation unit! Actually that's the main point, as if it's in the same TU, the compiler can probably figure out a function is pure.
  - dmitrygr 7y ago
    often but not always, for example a function using asm() to access, say, some AES intrinsics is pure (const even) since the output only depends on input, but oftentimes compiler by itself will not declare a function with an asm() block pure or const
    - einpoklum 7y ago
      Well, fair point, but - compilers shouldn't be that lazy :-)
WalterBright 7y ago
D has a `pure` attribute for functions, and yes it is enforced. It's enforced even to the point where it becomes a PITA, but when you manage to make functions pure, you know it's solid. One pain point with pure functions is you can't insert debug logging statements. D has a special case for that - purity for a statement isn't checked if it is prefixed with the `debug` keyword: pure int square(int x) { debug printf("called square\n"); return x * x; } which is very, very handy.
- Ididntdothis 7y ago
  This seems a very pragmatic solution.
- SomeOldThrow 7y ago
  This means you can't re-order the computation, though, or memoize it—at least not the the extent it's possible without IO.
  - mhh__ 7y ago
    The use of the debug {} block in D is opt-in e.g. the compiler only includes those statements when given the debug flag https://d.godbolt.org/z/Rwu4Cq https://d.godbolt.org/z/Rwu4Cq (remove "-d-debug" to see)
- Gibbon1 7y ago
  I wonder does that mean you could also enforce freeing memory allocated by a pure function as well?
  - mhh__ 7y ago
    I'm not sure what you mean? Allocators are often pure in D, they probably shouldn't be but that would mean allocating outside the function which would be ugly and probably buggy too
    - Gibbon1 7y ago
      Obviously a pure function can allocate memory on the stack. I would think it could also allocate memory on the heap, iff it was guaranteed that the memory was freed before the function exits. Was thinking that would be something the compiler would do. Forgive me I'm just a small brained firmware programmer.
      - ricattierger 7y ago
        So it seems that you are sort of talking about a function that is memoizable but not pure. Pure has no mutation of any global state. So hypothetically touching the heap means not pure - if somehow others can see it.

They are a promise and that is precisely what makes them powerful. It gives GCC info it might not be able to derive, but you know to be true. You can even promise a func is pure without even implementing it in the same translation unit! That produces lots of improvement. See these two godbolt links: https://godbolt.org/z/v2zqJI https://godbolt.org/z/v2zqJI https://godbolt.org/z/kk3Q3T https://godbolt.org/z/kk3Q3T

einpoklum 7y ago
> You can even promise a func is pure without even implementing it in the same translation unit! Actually that's the main point, as if it's in the same TU, the compiler can probably figure out a function is pure.
- dmitrygr 7y ago
  often but not always, for example a function using asm() to access, say, some AES intrinsics is pure (const even) since the output only depends on input, but oftentimes compiler by itself will not declare a function with an asm() block pure or const
  - einpoklum 7y ago
    Well, fair point, but - compilers shouldn't be that lazy :-)

WalterBright 7y ago

D has a `pure` attribute for functions, and yes it is enforced. It's enforced even to the point where it becomes a PITA, but when you manage to make functions pure, you know it's solid. One pain point with pure functions is you can't insert debug logging statements. D has a special case for that - purity for a statement isn't checked if it is prefixed with the `debug` keyword: pure int square(int x) { debug printf("called square\n"); return x * x; } which is very, very handy.

Ididntdothis 7y ago
This seems a very pragmatic solution.
SomeOldThrow 7y ago
This means you can't re-order the computation, though, or memoize it—at least not the the extent it's possible without IO.
- mhh__ 7y ago
  The use of the debug {} block in D is opt-in e.g. the compiler only includes those statements when given the debug flag https://d.godbolt.org/z/Rwu4Cq https://d.godbolt.org/z/Rwu4Cq (remove "-d-debug" to see)
Gibbon1 7y ago
I wonder does that mean you could also enforce freeing memory allocated by a pure function as well?
- mhh__ 7y ago
  I'm not sure what you mean? Allocators are often pure in D, they probably shouldn't be but that would mean allocating outside the function which would be ugly and probably buggy too
  - Gibbon1 7y ago
    Obviously a pure function can allocate memory on the stack. I would think it could also allocate memory on the heap, iff it was guaranteed that the memory was freed before the function exits. Was thinking that would be something the compiler would do. Forgive me I'm just a small brained firmware programmer.
    - ricattierger 7y ago
      So it seems that you are sort of talking about a function that is memoizable but not pure. Pure has no mutation of any global state. So hypothetically touching the heap means not pure - if somehow others can see it.