title: About Scala's assignments and setter methods
body: <p><strong>Edit: The bug which prompted this question <a href="https://issues.scala-lang.org/browse/SI-4237" rel="nofollow">has now been fixed</a>.</strong></p>
  
  <hr>
  
  <p>In the Scala Reference, I can read (p. 86):</p>
  
  <blockquote>
    <p>The interpretation of an assignment to
    a simple variable x = e depends on the
    definition of x. If x denotes a
    mutable variable, then the assignment
    changes the current value of x to be
    the result of evaluating the
    expression e. The type of e is
    expected to conform to the type of x.
    If x is a parameterless function
    defined in some template, and the same
    template contains a setter function
    x_= as member, then the assignment x =
    e is interpreted as the invocation
    x_=(e) of that setter function.
    Analogously, an assignment f .x = e to
    a parameterless function x is
    interpreted as the invocation f.x_=(e).</p>
  </blockquote>
  
  <p>So, for instance, something like this works fine:</p>
  
  <pre><code>class A {
    private var _a = 0
    def a = _a
    def a_=(a: Int) = _a = a
  }
  </code></pre>
  
  <p>I can then write</p>
  
  <pre><code>val a = new A
  a.a = 10
  </code></pre>
  
  <p>But if I define the class like this, adding a type parameter to method a:</p>
  
  <pre><code>class A {
    private var _a = 0
    def a[T] = _a
    def a_=(a: Int) = _a = a
  }
  </code></pre>
  
  <p>then it doesn't work any more; I get an <code>error: reassignment to val</code> if I write <code>a.a = 10</code>. Funny enough, it still works with no type parameter and an implicit parameter list, for instance.</p>
  
  <p>Arguably, in this example, the type parameter is not very useful, but in the design of DSLs, it would be great to have the setter method called even if the getter has type parameters (and by the way, adding type parameters on the setter is allowed and works fine).</p>
  
  <p>So I have three questions:</p>
  
  <ol>
  <li>Is there a workaround?</li>
  <li>Should the current behavior be considered a bug?</li>
  <li>Why does the compiler enforce a getter method to allow using the syntactic sugar for the setter?</li>
  </ol>
  
  <p><strong>UPDATE</strong></p>
  
  <p>Here's what I'm really trying to do. It's rather long, sorry, I meant to avoid it but I realized it was more confusing to omit it.</p>
  
  <p>I'm designing GUIs with SWT in Scala, and having huge fun using Dave Orme's <a href="http://www.coconut-palm-software.com/the_new_visual_editor/doku.php?id=blog%3asimplifying_swt_with_scala" rel="nofollow">XScalaWT</a>, which immensely reduces the amount of needed code. Here's an example from his blog post on how to create an SWT <code>Composite</code> that converts °C to °F degrees:</p>
  
  <pre><code>var fahrenheit: Text = null
  var celsius: Text = null
  
  composite(
    _.setLayout(new GridLayout(2, true)),
  
    label("Fahrenheit"),
    label("Celsius"),
  
    text(fahrenheit = _),
    text(celsius = _),
  
    button(
      "Fahrenheit =&gt; Celsius",
      {e : SelectionEvent =&gt; celcius.setText((5.0/9.0) * (fahrenheit - 32)) }
    ),
    button(
      "Celsius -&gt; Fahrenheit",
      {e : SelectionEvent =&gt; fahrenheit.setText((9.0/5.0) * celsius + 32) })
    )
  )
  </code></pre>
  
  <p>The argument to each of the widget-constructing methods is of type <code>(WidgetType =&gt; Any)*</code>, with a few useful implicit conversions, which for instance allow to directly specify a string for widgets that have a <code>setText()</code> method. All constructor functions are imported from a singleton object.</p>
  
  <p>In the end, I'd like to be able to write something along these lines:</p>
  
  <pre><code>val fieldEditable = new WritableValue // observable value
  
  composite(
    textField(
      editable &lt;=&gt; fieldEditable,
      editable = false
    ),
    checkbox(
      caption = "Editable",
      selection &lt;=&gt; fieldEditable
    )
  )
  </code></pre>
  
  <p>This would bind the editable property of the textfield to the selection of the checkbox through the WritableValue variable.</p>
  
  <p>First: named arguments are not applicable here, so the line <code>editable = false</code> has to come from somewhere. So, along the widget-constructing methods in the singleton object, I could write, conceptually,</p>
  
  <pre><code>def editable_=[T &lt;: HasEditable](value: Boolean) = (subject: T) =&gt; subject.setEditable(value)
  </code></pre>
  
  <p>... but this works only if the getter is also present. Great: I'd need the getter anyway in order to implement databinding with &lt;=>. Something like this:</p>
  
  <pre><code>def editable[T &lt;: HasEditable] = new BindingMaker((widget: T) =&gt; SWTObservables.observeEditable(widget))
  </code></pre>
  
  <p>If this worked, life would be good because I can then define &lt;=> in BindingMaker and I can use this nice syntax. But alas, the type parameter on the getter breaks the setter. Hence my original question: why would this simple type parameter affect whether the compiler decides to go ahead with the syntactic sugar for calling the setter? </p>
  
  <p>I hope this makes it a bit clearer now. Thanks for reading…</p>