Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add a flag to disallow expression statements different than void #8615

Closed
zpdDG4gta8XKpMCd opened this issue May 16, 2016 · 4 comments
Closed
Labels
Duplicate An existing issue was already created

Comments

@zpdDG4gta8XKpMCd
Copy link

zpdDG4gta8XKpMCd commented May 16, 2016

Problem:
Funtional programming needs better support in TypeScript. Values are everything in FP and in TypeScript the expression statements just silently discard them. Not being able to track places where the values are discarded leads to severe bugs. Example:

// before refactoring
function notify(message: string) : void {
    window.postMessage(message); // <-- assuming always works
}

// turns out that window.postMessage crashes when window gets closed
// need a check and a conditional result

// after refactoring
function notify(message: string) : Tried<void, 'cant-send-a-message'> {
    if (window.closed) {
        return failureFrom('cant-send-a-message');
    } else {
        return successFrom(window.postMessage(message));
    }
}

// after such change we need to make sure that all places that call `notify` are addressed
// it's easy to overlook those without a help from a compiler

Workaround:
use a linter rule

Solution:
add a flag to the compiler

@mhegazy
Copy link
Contributor

mhegazy commented May 16, 2016

looks like a duplicate of #8240

@mhegazy mhegazy added the Duplicate An existing issue was already created label May 16, 2016
@zpdDG4gta8XKpMCd
Copy link
Author

so the linter is the way?

@mhegazy
Copy link
Contributor

mhegazy commented May 16, 2016

I would want to bring it up for discussion again, since this is the third request in a few weeks for this feature.
I doubt anything will happen immediately as we do not have any precedence for the attribute/metadata syntax. ambient decorators (#2900) seems like a good candidate, but we do not have these yet.

@mhegazy
Copy link
Contributor

mhegazy commented May 16, 2016

closing in favor of #8240

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

2 participants