Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • Home
  • SEARCH
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 8791145
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: June 13, 20262026-06-13T22:48:11+00:00 2026-06-13T22:48:11+00:00

I always assumed that <var> += 1 and <var> = <var> + 1 have

  • 0

I always assumed that <var> += 1 and <var> = <var> + 1 have the same semantics in JS.
Now, this CoffeeScript code compiles to different JavaScript when applied to the global variable e:

a: ->
  e = e + 1
b: ->
  e += 1

Note that b uses the global variable, whereas a defines a local variable:

({
  a: function() {
    var e;
    return e = e + 1;
  },
  b: function() {
    return e += 1;
  }
});

Try it yourself.
Is this a bug or is there a reason why this is so?

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-06-13T22:48:11+00:00Added an answer on June 13, 2026 at 10:48 pm

    I think I would call this a bug or at least an undocumented edge case or ambiguity. I don’t see anything in the docs that explicitly specifies when a new local variable is created in CoffeeScript so it boils down to the usual

    We do X when the current implementation does X and that happens because the current implementation does it that way.

    sort of thing.

    The condition that seems to trigger the creation of a new variable is assignment: it looks like CoffeeScript decides to create a new variable when you try to give it a value. So this:

    a = ->
      e = e + 1
    

    becomes

    var a;
    a = function() {
      var e;
      return e = e + 1;
    };
    

    with a local e variable because you are explicitly assigning e a value. If you simply refer to e in an expression:

    b = ->
      e += 1
    

    then CoffeeScript won’t create a new variable because it doesn’t recognize that there’s an assignment to e in there. CS recognizes an expression but isn’t smart enough to see e +=1 as equivalent to e = e + 1.

    Interestingly enough, CS does recognize a problem when you use an op= form that is part of CoffeeScript but not JavaScript; for example:

    c = ->
      e ||= 11
    

    yields an error that:

    the variable “e” can’t be assigned with ||= because it has not been defined

    I think making a similar complaint about e += 1 would be sensible and consistent. Or all a op= b expressions should expand to a = a op b and be treated equally.


    If we look at the CoffeeScript source, we can see what’s going on. If you poke around a bit you’ll find that all the op= constructs end up going through Assign#compileNode:

    compileNode: (o) ->
      if isValue = @variable instanceof Value
        return @compilePatternMatch o if @variable.isArray() or @variable.isObject()
        return @compileSplice       o if @variable.isSplice()
        return @compileConditional  o if @context in ['||=', '&&=', '?=']
      #...
    

    so there is special handling for the CoffeeScript-specific op= conditional constructs as expected. A quick review suggests that a op= b for non-conditional op (i.e. ops other than ||, &&, and ?) pass straight on through to the JavaScript. So what’s going on with compileCondtional? Well, as expected, it checks that you’re not using undeclared variables:

    compileConditional: (o) ->
      [left, right] = @variable.cacheReference o
      # Disallow conditional assignment of undefined variables.
      if not left.properties.length and left.base instanceof Literal and 
             left.base.value != "this" and not o.scope.check left.base.value
        throw new Error "the variable \"#{left.base.value}\" can't be assigned with #{@context} because it has not been defined."
      #...
    

    There’s the error message that we see from -> a ||= 11 and a comment noting that you’re not allowed to a ||= b when a isn’t defined somewhere.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

I always assumed that some_function(...) was exactly the same as some_function.call(this, ...) . This
For some reason I have always assumed that most of the time a variable
Why do IDE's complain about leaking this in constructor? I've always assumed that it's
I always assumed that if I was using Select(x=> ...) in the context of
I always assumed caching the length of an array in JavaScript is a good
I've always assumed that DbNull.value was a singleton. And thus you could do things
I have a fairly complex piece of Javascript that works flawlessly with no errors
Is it safe to assume that $_SERVER['REMOTE_ADDR'] always returns a IPv4 address ? Thanks!
Is it safe to assume that java.util.concurrent.CompletionService.take().isDone() will always return true? If so, why
The Salesforce.com API seems to assume that you will always use the app as

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.