Comment #0 by verylonglogin.reg — 2015-01-20T20:47:02Z
If a function is executed during CTFE it's effectively `pure` for given parameters. This enhancement proposes to treat a function as a `pure` one in such contexts.
E.g. it will allow implicit conversion of a function result to `immutable`:
---
int g = 0;
int[] f(int i)
{
if(i)
++g;
return new int[1];
}
static immutable s1 = f(0); // OK
void main()
{
static immutable s2 = f(0); // OK
immutable s3 = f(0); // error, the context doesn't require CTFE
}
---
Pros:
Allow previously rejected but logically valid code to compile.
Cons:
Function return type is treated differently depending on a calling context (CTFE or not) which complicates language type system.
Comment #1 by verylonglogin.reg — 2015-01-20T20:56:35Z
Personally I'm against this language change as IMO:
* it creates a very strange exceptional rule in type system
* and I don't see much profit from it in real coding.
Here is an example of introduced language complication:
---
int[] f(int i) { return new int[1]; }
mixin template T()
{
immutable s = f(0); // OK or error? Depends on context.
}
mixin T; // OK here
void main()
{
mixin T; // error here
}
---
Note:
This issue is created as a result of Issue 7492 discussion.
P.S.
My general position is to not complicate the language without valuable profit in real projects even in cases of much smaller and non-exceptional rules.
Comment #2 by robert.schadek — 2024-12-13T18:39:03Z