add a modifier for pure functions

[zpdDG4gta8XKpMCd]

This is what pure means:

1. no destructive operations on parameters
2. all parameters must be guaranteed from being changed from the outside (immutable?)
3. no calls to any other callback/function/method/constructor that doesn't have the pure modifier
4. no reads from mutable values from a scope the pure function is closed over
5. no writes to values in the closed scope

[RyanCavanaugh]

We need more information about what you would expect this to do

[ivogabe]

A pure function does still not guarantee that a callback is invoked immediately:

function wrap(f: () => void) {
 return { f };
}
let x = Math.random() > 0.5 ? 'hey' : 1;
let obj: { f: () => void };
if (typeof x === 'number') {
 obj = wrap(() => x + 2);
}
x = '';
obj.f();

In my opinion, a better idea would be to narrow constant variables only in callbacks, as that would be sound.

[ivogabe]

I'd then say that only the callback has to be pure. In your example, narrowing could even happen when map is not pure, as it cannot modify the value of x (and if it would, the callback wouldn't be pure at all).

[edevine]

This would be boon to productivity, and would afford developers a practical tool to isolate side effects

const declaration + readonly modifier give us this:

no variables defined in the outside scope that are proven to possibly mutate can be used in a pure function

[zpdDG4gta8XKpMCd]

Eric Devine (@edevine), i would say it means

"const declaration + readonly modifier" for all sub-objects all the way down to the last primitives

[mhegazy]

For context we have discussed similar proposals as part of the readonly modifier support. see #6614 for more information.

[zpdDG4gta8XKpMCd]

related #8381

[tinganho]

A pure function does still not guarantee that a callback is invoked immediately:

Little bit OT, but I would like if TS can add an immediate modifier also to resolve the above problem:

declare interface Array<a> {
 map<b>(map: immediate (value: a) => b): b[]: 
}
let x = Math.random() > 0.5 ? 'hey' : 1;
if (typeof x === 'number') {
 [].map(() => x + 2); // no error callback is called immediately
}

function f(f: immediate () => void) {
 return { f }; // error callback must be called.
}

function f(f: immediate () => void) {
 return fs.readFileAsync(f); // error cannot call immediate callback async.
}

[malibuzios]

Aleksey-Bykov

'Pure' function means (wikipedia):

1. The function always evaluates the same result value given the same argument value(s). The function result value cannot depend on any hidden information or state that may change while program execution proceeds or between different executions of the program, nor can it depend on any external input from I/O devices (usually—see below).
2. Evaluation of the result does not cause any semantically observable side effect or output, such as mutation of mutable objects or output to I/O devices (usually—see below).

In order to satisfy (1.) this would mean it would also exclude read operations to any captured entity and global scope entity (window, document, etc.). The only remotely possible exceptions here are captured constants with a primitive type like number, string, boolean etc., however even they can technically have properties, so even if property access is prevented on them, they could still be returned from the function, and potentially the caller would receive a different return value between calls. This means the function couldn't basically read or write from/to anything outside of it, including captured variables (or possibly constants) from another pure function, as those are not guaranteed to have the same value at each execution.

It may be that the analysis is actually easier than the one that's needed for #8353, but I'm not sure.. maybe it's safe to simply say it's 'different'.

[malibuzios]

Maybe the intention here wasn't really for 'pure' functions in the conventional sense, but a form of a non-side-effecting function, that could still return different values at each execution but is 'guaranteed' not to silently influence the state (including, say things like I/O). That would be closer to the analysis needed for #8353, but would include more components like modification of properties (which isn't really included there, it is only about reassignments), having an understanding of I/O related operations etc.

[malibuzios]

I can see possible side effects from getters being a problem, so this would mean that there should be some way to detect regular interface properties (not methods) that could still have side effects, so using readonly wouldn't be sufficient here:

interface MyInterface {
 readonly prop: number; 
}

class MyClass implements MyInterface {
 get prop(): number {
 mutateGlobalState();
 return 1;
 }
}

nonmutating function imSupposedToHaveNoSideEffects(arg: MyInterface) {
 let num = arg.prop;
}

imSupposedToHaveNoSideEffects(new MyClass())

It needs to be something like:

interface MyInterface {
 nonmutating readonly prop: number; 
}

(I'm using the nonmutating modifier here temporarily, just for illustration, perhaps there's a better one for this)

[Edit: Modified the code example to make it a bit clearer]
[Edit: Or maybe the whole interface or class should be tagged as nonmutating?]

[zpdDG4gta8XKpMCd]

this is what 3 is about: anything closed over by a pure function has to be
immutable, or else being pure should not typecheck
On May 1, 2016 5:14 AM, "malibuzios" notifications@github.com wrote:

I can see possible side effects from getters being a problem, so this
would mean that there should be some way to detect readonly interface
properties that could still have side effects, so using readonly wouldn't
be sufficient here:

interface MyInterface {
readonly prop: number;
}
class MyClass implements MyInterface{
get prop(): number {
mutateGlobalState();
return 1;
}
}

nonmutating function imSupposedToHaveNoSideEffects() {
let x = new MyClass();
let num = x.prop;
}

It needs to be something like:

interface MyInterface {
nonmutating readonly prop: number;
}

(I'm using the nonmutating modifier here temporarily, just for
illustration, perhaps there's a better one for this)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#7770 (comment)