Use := for Assignment

[odersky]

Since we are close to feature freeze, I'd like to discuss the last remaining point that remains open for me. Should we use := instead of = for assignments? I left it lying for a long time since I hesitated to wake up a sleeping dog. Almost everybody else uses = for assignment. So the path of least resistance is to continue using = in Scala. However, now that I am actually very happy about the syntax we have achieved, using = for assignments sticks out like a sore thumb. So before accepting the status quo, I wanted to at least make the argument why one would want to switch.

Consider:

def incr = x = x + 1

This is terribly wrong on several levels. It's hard to parse and uses equals for two fundamentally different things. By itself, x = x + 1 makes no sense either, and requires embarrassing explanations for everyone new to programming.

Other languages don't have the problem to the same degree, since they don't use = for definitions. For instance, in Java or Python, you could read = as always meaning assignment. The incr example looks like this in these languages:

int incr() { 
  x = x + 1;
}

def incr():
  x = x + 1

But in Scala, we do use = for definitions, which makes the abuse of the operator in assignments so much worse.

:= is a natural alternative. It's used in every serious treatment of imperative programming logics and is also used in quite a few languages, including Algol, Pascal, OCaml, F#, Go. Using := instead of = makes imperative operations visually more distinct from functional ones, which is a good thing.

:= can be treated by the same rules as operator assignments. That is, in a := b, if the left hand side has an applicable method named := the assignment is rewritten to a.:=(b). I believe we can roll the existing syntactic expansion of = to update calls into the same logic, which would simplify the desugaring rules.

Migration: Scala 3.0 should allow = and :=. = would be deprecated at some later version. This will probably take some time.

[lrytz]

Could you clarify if array(i) = x would stay the same, or be written array(i) := x?

[odersky]

I believe it should be written array(i) := x.

[sjrd]

This change does not play well with the desugaring of op= operators:

i += 1

now desugars into

i := i + 1

while

xs +:= 5

desugars into

xs := xs.+:(5)

[jducoeur]

Poking at this, it sounds like you're suggesting := for assignment, but leaving = for definition. This raises several questions.

Most obviously, what does a var declaration look like? Are we saying:

var x := 1

or

var x = 1

Either way, it winds up feeling rather asymmetrical against:

val y = 2
x := 3

And @sjrd beat me to talking about +=.

While I'm not dead-set against this one, I think I'm against trying to rush it into 3.0 this late in the process. This would have to happen slowly, over several releases, anyway, so I don't think it qualifies for the "rewrite all the textbooks" argument. I'd recommend putting this one off and giving it sufficient time for thought and experiment...

[odersky]

I believe a var declaration should also use :=.

  var x := 1

One can argue either way, but ultimately, that's the safe choice. The fact that it's different from val x = 2 is actually a good thing, since val and var are too easily confused today.

Operators: I don't see the problem. x op= y desugars to x := x op y, unless op is : in which case it stays as it is.

[dwijnand]

What would you suggest to user-land code that made use of :=, like sbt? Outside of being able to backtick-escape :=.

[smarter]

Yes, there's a ton of DSLs that heavily use :=, besides sbt I can think on top of my head of chisel (https://www.chisel-lang.org/), scalatags (http://www.lihaoyi.com/scalatags/) and scalajs-react (https://japgolly.github.io/scalajs-react/#examples/ajax-1).

[odersky]

@dwijnand That is addressed by

:= can be treated by the same rules as operator assignments. That is, in a := b, if the left hand side has an applicable method named := the assignment is rewritten to a.:=(b).

[sjrd]

Hum but then how do you actually assign something to a var whose type has a := method?

[sjrd]

Another thing: this will not work well with setters defined as

def x: Int = ...
def x_=(v: Int): Unit = ...

How do you explain that

foo.x := 5

desugars into

foo.x_=(5)

and not

foo.x_:=(5)

[odersky]

Yes, setters are an issue. For compatibility we probably have to leave them as x_=, even though it's not ideal.

[odersky]

Hum but then how do you actually assign something to a var whose type has a := method?

You mean a := method that is applicable to the right hand side, i.e. to the type of the variable itself? That looks like a pretty extreme and nonsensical case. If you do that then maybe you should not be able to assign to such a var.

[dwijnand]

If you do that then maybe you should not be able to assign to such a var.

Or maybe you're forced to backtick-escape:

var foo = SettingKey[String]("foo", "")
foo := SettingKey[String]("foo", "Use foo to foo")
foo `:=` "bob"

[odersky]

Or maybe you're forced to backtick-escape:

Yes, maybe we can add a special rule that backtick-escape always means straight assignment. But I'd like to see some actual use cases first.

[abgruszecki]

I don't think any special rule is necessary - wrapping the LHS in parenthesis (i.e. (x) := 5) suffices to disambiguate assignment vs calling a method.

[soronpo]

What about extension methods (currently via implicit classes) that use :=?

[odersky]

I don't think any special rule is necessary - wrapping the LHS in parenthesis (i.e. (x) := 5) suffices to disambiguate assignment vs calling a method.

No, since the priority goes the other way: if the variable's type has an applicable method := the method call takes precedence.

[odersky]

What about extension methods (currently via implicit classes) that use :=?

It's exactly the same rules as for assignment operators. So, extension methods are supported.

[soronpo]

FWIW, I develop a DSL that uses :=. I created a macro to that rejects DSL terms from being assigned to var, so the user cannot write var foo = DSLTerm(). Thus the logic for this proposal is sound, IMO, but I'm worried maybe not all DSLs follow this concept.

[liufengyun]

Using := instead of = makes imperative operations visually more distinct from functional ones, which is a good thing.

Just want to add that Scala already achieves this: initialization/definition and mutation can be distinguished in syntax easily. Given any code snippet, it's easy to find all mutations on the first sight. This is not true in Java, where an immutable final field can be initialized via assignment.

For language ergonomics, when there is no syntactic ambiguity and semantic ambiguity for the compiler and for programmers, reuse of the same symbol may be beneficial. For example, in natural languages:

• 1 plus 1 is 2
• The movie is great
• "He is free now", the judge says (effects here!)
• Tom is a student
• There is a cat

In each sentence, the meaning of is is different.

[lihaoyi]

I don't mind this change either way, as long as things like Scalatags or Scala-Js-React do not break, but this line sticks out:

That is, in a := b, if the left hand side has an applicable method named := the assignment is rewritten to a.:=(b).

Does that mean a var thing: {def := } could never be mutated? That doesn't seem like a particularly good outcome. In particular, the way update is de-sugared isn't comparable at all because it is ambiguous: foo(x) = y cannot be anything else other than an .update call.

Maybe var thing: {def := } is an uncommon scenario to be in, but we shouldn't make uncommon scenarios impossible

[nafg]

Can we not change things unless there is a really, really strrong reason? def incr = x = x + 1

This is terribly wrong on several levels. It's hard to parse and uses equals for two fundamentally different things. By itself, x = x + 1 makes no sense either, and requires embarrassing explanations for everyone new to programming.

I don't buy this argument. 1. It's not hard to parse, and if it is you can break it up onto another line. How common is this anyway? 2. The two uses of equals are close enough and unambiguous enough that there's nothing wrong with using the same symbol for both. 3. I don't see how x := x + 1 makes any more sense than x = x + 1. Maybe what's confusing is that the idea of a var is confusing. So let people program more functionally and this issue is irrelevant. Maybe reassignment is an advanced feature that shouldn't be taught too early. In any case one can always write x_=(x + 1)... (Technically, IIUC := is more appropriate for a definition than for reassignment, but of course it would be even worse to change definition syntax.)

…

On Thu, Nov 21, 2019 at 10:28 PM Li Haoyi ***@***.***> wrote: I don't mind this change either way, as long as things like Scalatags or Scala-Js-React do not break, but this line sticks out: That is, in a := b, if the left hand side has an applicable method named := the assignment is rewritten to a.:=(b). Does that mean a var thing: {def := } could never be mutated? That doesn't seem like a particularly good outcome. In particular, the way update is de-sugared isn't comparable at all because it is ambiguous: foo(x) = y cannot be anything else other than an .update call. Maybe var thing: {def := } is an uncommon scenario to be in, but we shouldn't make uncommon scenarios impossible — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7598>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYAUEMFC3PYOOIXJUDYFTQU5GWJANCNFSM4JQA26SA> .

[odersky]

Does that mean a var thing: {def := } could never be mutated?

We had a discussion about this above, but for clarity let me add the full types:

class Ref[X] { def := (x: X): Unit = ??? }
var x, y: Ref[Int] = new Ref[Int] 
x := 1    // calls the method
y := x    // is a primitive assignment, since the method is not applicable

We would make assignments impossible if we defined Ref like this:

class Ref[X] { def := (x: Any): Unit = ??? }

Maybe we need an escape hatch for these situations such as putting := in backticks. But I assume it's such a weird use case that we do not need to worry about it.

[jdegoes]

I like this proposal. In Haskell, the use of = is confusing in places (data Foo = Bar | Baz). It'd be nice to see Scala clean up on this ambiguity.

One small thought: Scala excels at DSLs, and var is just one type of mutable reference: AtomicReference is another (with get / set / update capabilities), and ZIO's Ref provides yet another.

It'd be nice if var x became, conceptually at least, if not in implementation (for performance reasons), something like val x = new Var[Int], such that val is the only conceptual primitive and all var assignment and mutation are just syntax for method calls on objects.

This would open the playing field to alternate versions of var such as one built on atomic reference that provides visibility and synchronization guarantees:

val ref = new AtomicRef[Int](0)

ref := 1 // ref.:=(1)
ref := 2 // ref.:=(2)
ref += 4 // ref.update(_ + 4)

[wojtek-tg]

In my opinion the cost of introducing this change (code, corner cases, making people like it and use it) is bigger than the gains from this change.

[soronpo]

It'd be nice if var x became, conceptually at least, if not in implementation (for performance reasons), something like val x = new Var[Int], such that val is the only conceptual primitive and all var assignment and mutation are just syntax for method calls on objects.

This was once implemented in the Virtualized Scala fork.

[lbialy]

Will the return type of new assignment operator still be Unit or will it return the type and value of value assigned allowing for while (c := inputStream.read(buf) != -1) { syntax? This change could mirror Python's PEP 572 - assignment expression and bring similar functionality into Scala.

[LPTK]

@lbialy I think this pattern is an ugly hack for imperative languages to make up for the fact that they don't have an expression-based syntax. In Scala, you'd just write:

while ({ c := inputStream.read(buf); c != -1 }) { ... }

And with the new control syntax it would become the more elegant:

while { c := inputStream.read(buf); c != -1 } do { ... }

[ilhanyumer]

Another option is to use <-. In R you can assign variables like this:
var1 <- 11
or
22 -> var2

[lihaoyi-databricks]

Maybe we need an escape hatch for these situations such as putting := in backticks. But I assume it's such a weird use case that we do not need to worry about it.

I think we need an escape hatch. "oh you cannot ever assign vars of these types, due to syntactic reasons" seems a pretty good reason to disqualify a syntax entirely. Having things like a *= b multiple-and-assign syntax not work in some cases is fine, because people can fall back to the full a = a * b. When a = b doesn't work, what do they fall back to?

We shouldn't be willing to take shortcuts for common cases at the expense of making uncommon cases literally impossible.

[eatkins]

I've been thinking about this proposal for a few days now and the more I think about it the more I like it. It improves clarity by distinguishing definition and assignment (the def incr = x = x + 1 example is truly an abomination) and it imposes a syntactic penalty for mutation. I have long been bothered by the fact that var and val are the same length and differ by just a single character. The visual distinction between := and = is much more obvious that var vs val.

At a glance, I don't like the new proposal by @lihaoyi directly above this comment because it seems to only address the def incr ugliness and neither addresses the ambiguity of definition vs assignment nor imposes a syntactic penalty for mutation.

It's unfortunate that a good amount of the discussion in this thread (and in other channels) has been rather reactionary and not really about the merits or demerits of the proposal. Regardless of whether or not this proposal is accepted, I find it difficult to imagine that the success of scala 3 is contingent on this minor (though still quite beneficial in my view) syntactic change. I also find the notion that new and existing developers will struggle with learning := collectively insulting to their intelligence.

The points that Heather Miller made in her scale by the bay keynote are relevant to the current scala 3 hysteria. The software development field is growing so quickly that newcomers will outnumber the old heads in the blink of an eye. If 70% of scala 2 users abandoned scala due to the scala 3 changes, scala 3 could still be an enormous success if it spurred growth in new areas. The growth trends for scala 2 do not seem great so it seems foolish to bend over backwards to accommodate all of the legacy use cases. For all the handwringing about the python 2/3 split, last time I checked it was both one of the most popular languages and fastest growing. Right now, scala can't really make either claim.

[eatkins]

I don't think this is a good way to gatekeep discussion. Most of us do not have the ability to use an experimental fork of a niche language full time, nevermind for a couple of months! After all, we already have full time jobs, and million-line Scala codebases that we're not going to port to dotty in the next week.

This requirement basically limits the discussion to those who work full time at EPFL on Dotty, locks everyone else out, and dismisses years of industry experience as "stockholme syndrome". Not exactly an inclusive, collaborative, or diverse basis to begin a discussion; likely you'll find the only input that passes that bar is your own.

What would you propose as an alternative to the dotty status quo for getting feedback on new language syntax? I have read a number of blog posts about experimenting with dotty which imply that a number of non-epfl people (including people working in industry as well as hobbyists) have been tinkering with dotty. It would certainly be foolish to disregard feedback from anyone out of hand -- and I doubt that @odersky literally meant that you need to use dotty for months to offer feedback even if the stockholm syndrome comment was a bit alienating -- but he has a point that often you do have to try something for a while to properly evaluate it. I've learned this is the case with restaurants just as much as programming. I fear that if progress in scala is dictated by industry and reddit threads, it will pander to the lowest common denominator.

[lihaoyi]

What would you propose as an alternative to the dotty status quo for getting feedback on new language syntax?

Respect for people's experience, history of contributions, demonstrated competence, and knowing what they want is a reasonable alternative. People here have years-to-decades long careers working in dozens of different languages and environments, many of which have syntax similar to that being proposed. We're not a class of 1st year undergraduates.

Imagine if you were a salesperson trying to hawk some SAAS software, and your sales pitch was "you have to try it for months, we promise you that you'll grow to like it". They'd think you're crazy, and for good reason, because you probably are.

The whole point of a design document/proposal/discussion process is to build consensus without everyone having to spend large amounts of time becoming invested in something. If the document is "here it is, ready or not" and the discussion is "try it for a few weeks/months, I think you'll like it", the entire process has failed. Such a design document/proposal would never pass muster in any professional environment.

[eatkins]

Respect for people's experience, history of contributions, demonstrated competence, and knowing what they want is a reasonable alternative. People here have years-to-decades long careers working in dozens of different languages and environments, many of which have syntax similar to that being proposed. We're not a class of 1st year undergraduates.

Imagine if you were a salesperson trying to hawk some SAAS software, and your sales pitch was "you have to try it for months, we promise you that you'll grow to like it". They'd think you're crazy, and for good reason, because you probably are.

Wow. That was a very respectful response! Thank you.

[nafg]

Ethan, he wasn't talking about you! https://www.dictionary.com/browse/you I agree with Li Haoyi. Furthermore, even if 5 or 20 or 100 people do feel more productive after using it for 3 months, that doesn't mean there can't be valid reasons not to ship something in 3.0. (1) Feeling more productive can be subjective. So disregarding people's input is never valid. (That doesn't mean everyone has veto power, but every argument has to be considered.) It might make other people less productive. (2) Even if it only makes people more productive, you also have to take into account the PR effect changes have. If the result is going to be a spate of rants on dzone and reddit about how scala has gone off the rails, it's not going to help with scala's adoption and perception issues.

…

On Sun, Nov 24, 2019 at 8:25 PM Ethan Atkins ***@***.***> wrote: Respect for people's experience, history of contributions, demonstrated competence, and knowing what they want is a reasonable alternative. People here have years-to-decades long careers working in dozens of different languages and environments, many of which have syntax similar to that being proposed. We're not a class of 1st year undergraduates. Imagine if you were a salesperson trying to hawk some SAAS software, and your sales pitch was "you have to try it for months, we promise you that you'll grow to like it". They'd think you're crazy, and for good reason, because you probably are. Wow. That was a very respectful response! Thank you. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7598>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYAUF2IJZNI57A34FYAUTQVMSQFANCNFSM4JQA26SA> .

[odersky]

I am sorry if the remark about Stockholm syndrome irked people - it was meant as a figure of speech. I believe my history of interactions has shown that I do value and take into account feedback everywhere. Otherwise I would not spend considerable time engaging in this discussions! And, yes, there are a number of dimensions that need to be brought up, some of them technical, the others issues of perception. On the technical and UX issues I tend to give more weight to the opinions of people who have actually tried the stuff.

What I tried to convey in my comment that seemingly went over badly is my enthusiasm for what a great language we have achieved! It's a really pleasing experience to write serious code in Scala 3. I would never have thought that the combination of small syntax changes would have such a dramatic effect on usability. And in my opinion that aspect has to be experienced, you can't give it justice if you have not tried it.

[sirthias]

While I can see the value in making mutation stand out more and be set apart from definition, on a syntactical level, I fear that the overal cost/benefit ratio of the proposed change is negative.

Consider these two definitions:

val x = 1
var y = 1

While from a more higher-level, functional perspective these two things might be two entirely different things they compile down to very same byte code: Writing a value into to a "named" memory location. To people coming to Scala from more imperative Languages the difference between x and y only manifests itself in the things that can be done to x and y, specifically that y can be "changed".
The initialization of x and y however is exactly the same operation, down to the machine level.
Therefore, from in imperative viewpoint, I'd say the snippet above captures the essence of the two definitions perfectly.

This, however, appears less principled:

val x = 1
var y := 1

The difference between x and y is already expressed via the val vs. var keywords. The initialization operation itself is identical but now requires two different syntaxes. When seen on a low level there is only one difference between x and y, namely that y can receive a different value later vs. x can't, and this difference doesn't even manifest itself on these lines themselves but only on the lines using these definitions.
Yet, we now have to change val x = 1 in two places to turn it into a true "variable" and it now looks as if the initialization code were somehow different between the two lines.

I fear that this would confuse people coming to Scala from imperative languages, while the first snippet is perfectly clear.
So, the benefit to new Scala users could be negative, especially at the very beginning.

Is this disadvantage then overcompensated by benefits reaped later when people have more experience and work in more idiomatic Scala codebases?
I'd say no.
This change would affect an area of the language that, while I'd consider it a crucially important part, is rightfully used less and less the more experience one gains with the language. Many idiomatic Scala codebases hardly use any vars at all.
So any improvements to their syntax won't really make any difference to them.
vars are simply too rare.

Therefore we are faced with a proposal that has a high risk of being unhelpful to newcomers while at the same time provides little benefit to the already large, existing user base. Especially when viewed under the principle that changes to the language must present a relatively large improvement over the status quo in order to offset the considerable cost of the change itself, I'd say that the best way forward would be to leave things as is.

[ghost]

IMO forcing brackets is much more acceptable than replacing = with := for assignment, and

def incr = { x = x + 1 }

looks okay to me. This is also the case for forcing indentation.

[nafg]

Agreed. Even if assignment syntax is changed for some reason to :=, a var should still be defined with =. There is a very elegant symmetry in val, var, and def having the same syntax, after all they're the same thing, assigning a name to an expression, except for different semantics about the specifics of that, and because of def's semantics it can also have parameters. If you like, call := the *re*assignment operator. (I still don't think the change is motivated enough to justify it, but if it is, I would still argue the above.)

…

On Mon, Nov 25, 2019 at 5:53 AM Mathias ***@***.***> wrote: While I can see the value in making mutation stand out more and be set apart from definition, on a syntactical level, I fear that the overal cost/benefit ratio of the proposed change is negative. Consider these two definitions: val x = 1var y = 1 While from a more higher-level, functional perspective these two things might be two entirely different things they compile down to very same byte code: Writing a value into to a "named" memory location. To people coming to Scala from more imperative Languages the difference between x and y only manifests itself in the things that can be done to x and y, specifically that y can be "changed". The *initialization* of x and y however is exactly the same operation, down to the machine level. Therefore, from in imperative viewpoint, I'd say the snippet above captures the essence of the two definitions perfectly. This, however, appears less principled: val x = 1var y := 1 The difference between x and y is already expressed via the val vs. var keywords. The initialization operation itself is identical but now requires two different syntaxes. When seen on a low level there is only *one* difference between x and y, namely that y can receive a different value later vs. x can't, and this difference doesn't even manifest itself on these lines themselves but only on the lines *using* these definitions. Yet, we now have to change val x = 1 in *two* places to turn it into a true "variable" and it now looks as if the initialization code were somehow different between the two lines. I fear that this would confuse people coming to Scala from imperative languages, while the first snippet is perfectly clear. So, the benefit to new Scala users could be negative, especially at the very beginning. Is this disadvantage then overcompensated by benefits reaped later when people have more experience and work in more idiomatic Scala codebases? I'd say no. This change would affect an area of the language that, while I'd consider it a crucially important part, is rightfully used less and less the more experience one gains with the language. Many idiomatic Scala codebases hardly use any vars at all. So any improvements to their syntax won't really make any difference to them. vars are simply too rare. Therefore we are faced with a proposal that has a high risk of being unhelpful to newcomers while at the same time provides little benefit to the already large, existing user base. Especially when viewed under the principle that changes to the language must present a relatively large improvement over the status quo in order to offset the considerable cost of the change itself, I'd say that the best way forward would be to leave things as is. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7598>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYAUE3G3YN7P4H56OPTT3QVOVBLANCNFSM4JQA26SA> .

[Jasper-M]

Migration: Scala 3.0 should allow = and :=. = would be deprecated at some later version. This will probably take some time.

I have now read lines similar to this one in many proposals. Regardless of the proposal, every time I read a line like that it scares me a little bit more.

I realize that it's necessary to be able to compile as much Scala2 code with Scala3 as possible. But by the time Scala 3.0 gets released it will contain so many new things—and still support all the old things they are supposed to replace—that all the permutations of ways to write the same piece of code will have exploded exponentially. Am I the only one who fears that this might cause Scala 3 to be viewed by some as a huge pile of unrelated syntax and features, while the goal was actually to make things simpler and reduce the amount of ways to do the same thing?

Even if everyone was disciplined enough (then why is the simplification even necessary?) to only write new code with the new syntax, you'd still get codebases that are a mix of new things and old things, and new developers would still need to learn all the old stuff too, including how all the old stuff interacts with the new stuff.

[dwijnand]

If you need a graceful migration, then you need a period in which both are supported. Otherwise, you can't change things.

[lihaoyi]

I would never have thought that the combination of small syntax changes would have such a dramatic effect on usability. And in my opinion that aspect has to be experienced, you can't give it justice if you have not tried it.

Most of us have tried the various features in other contexts though; we're not only writing Scala!

• Many have experienced indentation-delimited blocks writing Python. It's the most popular language in the world after all. Some people love it, some people love it enough to have ported it to Scala 5 years ago, and yet others hate it with a burning passion.

• Many have experienced various languages using :=, and various languages using different delimiters for variable initialization and update: Go uses := and =, F# uses = and <-. It's really not that new an idea.

There's also the flip side: that many are experiencing things that someone full time working on Dotty and teaching undergraduates using Scala might not be experiencing:

• Large codebases stuck on an endless upgrade treadmill, 24/7 365 days a year upgrading between already-old versions of the language, where compatibility flags are a lifesaver in allowing you to upgrade, even as they reduce the "purity" of the language spec.

• Teams who are not Scala enthusiasts, couldn't care less about language syntax, and value non-breaking improvements that make their lives better at no cost

• Maintaining large open source Scala libraries and ecosystems, using many Scala language features, and exercising Scala in a wide variety of fields and domains that are not "we are writing a Scala compiler" or "Programming 101"

it's entirely possible that a change massively benefits someone writing Scala compilers and teaching undergraduates, and still have the change do great harm to someone running the upgrade treadmill on an old project, or selling Scala to a non-language-enthusiast team. It's entirely possible that a change makes Scala look great to a Python enthusiast, while making it look horrible to a Python un-enthusiast. There is no contradiction here.

Which is why I keep arguing against "try it, maybe you'll like it". It's a useless piece of information. Even if I quit my job tomorrow and spent the next 3 months and spent 40 hours a week using a new feature on some project, it would tell me exactly nothing about how well that feature plays in a large professional codebase. It would tell me nothing about how the feature will play in the maintenance of my suite of open source libraries.

In many of these contexts, I can already predict how a change would play out; after all, one role of a software developer is to help predict the effect of a change before investing days/weeks/years in executing on it. It's literally our job!

And that's the purpose of of a proper design proposal/document/review: to get everyone's input, from all their different backgrounds, their predictions on how a change might impact them, without having to perform expensive (and ultimately unhelpful) experiments and investments.

If you prioritize feedback from hands-on Dotty experience, you are prioritizing feedback from people teaching undergraduates, writing Scala compilers, write toy side projects, since those are the only use cases for Dotty right now. It wouldn't be surprising at all if you then end up creating a Scala language optimized for teaching undergraduates, writing Scala compilers, and writing toy projects, at the expense of everything and everyone else. After all, nobody's going to come to you next week and tell you their experience porting their million-line hundred-developer enterprise codebase to Dotty.

[Jasper-M]

If you need a graceful migration, then you need a period in which both are supported. Otherwise, you can't change things.

Sure but my fear was that there comes a point where the resulting language is no longer graceful.

[bishabosha]

Maybe it looks ugly, but no identifier will ever clash with _=, but at least it aligns with setters

var x = 0
while x < 100 do
  x _= x + 1

or perhaps ugly is precisely what we need :)

[Sciss]

no identifier will ever clash with _=

It's not a valid identifier:

trait Ref {
  def _= (value: Any): Unit
}

<console>:2: error: identifier expected but '_' found.
         def _= (value: Any): Unit
             ^

You would at least need to use two underscores, like __=. Anyway, I don't see any problem for := if you can force method invocation through backticks.

[dwijnand]

Sure but my fear was that there comes a point where the resulting language is no longer graceful.

It's a valid fear. In fact, he Dotty repo is a way to combat that: instead of just evaluating language features in a vacuum, it's implemented a number of features, to test how graceful the resulting language functions.

[odersky]

@lihaoyi Just to put some facts straight:

• I do a bit more than teaching undergraduates. Through my books and MOOCs I have taught several hundreds of thousands of programmers (total inscriptions have reached 1 Million by now). According to our statistics, 85% of them were professionals (had a first degree).

• We also do a bit more than writing compilers. It's also the standard library, and the IDE, and the doc tool, and porting stuff to the Dotty community build (you will see your own libraries in that build shortly). It's true that this is still a fairly special slice of the whole ecosystem; for instance one particularity is that we are sitting at the bottom of the food chain with almost no dependencies. So, yes, other people have other problems which might make them have other priorities.

All I wrote was that in my experience Scala 3 is shaping up to be a great language. You may believe that or not. But there's no need to denigrate the messenger.

[lihaoyi]

Sorry, I do not mean to denigrate anyone. Just explaining that I think “try it out” is neither necessary nor sufficient to get a good read of things in many scenarios, and prioritizing trying it out may overfit on use-cases where trying out experimental tools and changes is easier

…

On Mon, 25 Nov 2019 at 9:18 AM, odersky ***@***.***> wrote: @lihaoyi <https://github.com/lihaoyi> Just to put some facts straight: - I do a bit more than teaching undergraduates. Through my books and MOOCs I have taught several hundreds of thousands of programmers (total inscriptions have reached 1 Million by now). According to our statistics, 85% of them were professionals (had a first degree). - We also do a bit more than writing compilers. It's also the standard library, and the IDE, and the doc tool, and porting stuff to the Dotty community build (you will see your own libraries in that build shortly). It's true that this is still a fairly special slice of the whole ecosystem; for instance one particularity is that we are sitting at the bottom of the food chain with almost no dependencies. So, yes, other people have other problems which might make them have other priorities. All I wrote was that in my experience Scala 3 is shaping up to be a great language. You may believe that or not. But there's no need to denigrate the messenger. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7598>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHEB7FTJKPXIEJV4QP7KO3QVQCFRANCNFSM4JQA26SA> .

[odersky]

Guido Van Rossum retired over :=. I decided that I do not want to share the same fate (yet). 😉 I still think changing assignment to := would be the right thing in isolation, but the realities make it messy

• We have to leave setters x_= as they are; so that would give an inconsistency wrt :=.
• The cost of migration would be high.

I have not shied away in the past from proposing to change language features that have a migration cost. But in this case, in the end, the change just does not seem important enough. Maybe syntax highlighting could render assignment equals different from definition equals. That would be a tooling solution to some of the problems.

[neontorrent]

@lihaoyi Just to put some facts straight:

• I do a bit more than teaching undergraduates. Through my books and MOOCs I have taught several hundreds of thousands of programmers (total inscriptions have reached 1 Million by now). According to our statistics, 85% of them were professionals (had a first degree).
• We also do a bit more than writing compilers. It's also the standard library, and the IDE, and the doc tool, and porting stuff to the Dotty community build (you will see your own libraries in that build shortly). It's true that this is still a fairly special slice of the whole ecosystem; for instance one particularity is that we are sitting at the bottom of the food chain with almost no dependencies. So, yes, other people have other problems which might make them have other priorities.

All I wrote was that in my experience Scala 3 is shaping up to be a great language. You may believe that or not. But there's no need to denigrate the messenger.

I feel like you are taking this the wrong way. I do think these changes are going to make the language better, but better language doesn't mean better adoption or acceptance. If you look at the top language list, they are all horrible languages. But still people use them widely.

Currently Scala is used more than just a teaching or toy language. People use it in the industry, so any change will introduce cost and we are talking real money, and being comfortable to use isn't gonna justify that.

[nafg]

Right but it's an argument in favor of staggering changes over several releases

…

On Mon, Nov 25, 2019, 10:26 AM Dale Wijnand ***@***.***> wrote: If you need a graceful migration, then you need a period in which both are supported. Otherwise, you can't change things. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7598>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYAUDBXBWO5KWY6XFLSATQVPVA7ANCNFSM4JQA26SA> .

[fkowal]

@dwijnand reminded quite an important issue

If you need a graceful migration, then you need a period in which both are supported. Otherwise, you can't change things.

If this new syntax for assignment would be introduced gracefully,

1. Scala 3 it's totally optional, where x = x + 1 and x := x + 1 are valid and mean exactly the same thing
2. Scala 3.x x = x + 1 becomes a deprecated
3. Scala 3.y x := x + 1 is the only supported syntax

the pushback and concerns a specially from library authors could be addressed by giving a clear deprecation period.

I very much like this proposal, but also am a bit concerned about the negative impact.

So big 👍 for @odersky and everyone else who participates in such important discussions

[s5bug]

The amount of issues and conflicts that have arisen with :=, especially since the original example was

def incr = x = x + 1

makes @lihaoyi's suggested solution of forcing curly braces much more appealing than a walrus operator.

I know it's been said before, but not only are you saving a reserved operator, you don't have to teach anything new to anyone who already knows what {} does. Additionally, you can have the compiler treat a var assignment as a statement as @lihaoyi said, and have it automatically convert to an expression & spit out a warning during the period between 3.x and 3.y.

I very rarely use vars in my code but I commonly use DSLs with :=, so that's the biggest part of this issue that would affect me (writing `:=` everywhere).

[soronpo]

I very rarely use vars in my code but I commonly use DSLs with :=, so that's the biggest part of this issue that would affect me (writing := everywhere).

As I understand it, this proposal does not prevent using := in DSL (without backticks).

[pavelfatin]

Speaking of IDEs:

• https://youtrack.jetbrains.com/issue/SCL-16671 Show : inlay hint in assignments to vars
• https://youtrack.jetbrains.com/issue/SCL-16672 Make var identifiers look different
• https://youtrack.jetbrains.com/issue/SCL-16673 Inspection: expression of Unit type is used as a value

[odersky]

@pavelfatin I like it!

[Rich2]

I've used it for years in a language called, Simple Build Tool, I didn't like it when I first came across it and I don't like it now. Such a change would only make sense if the ==, was being changed to = for equality.

[sasha2048]

I had liked this proposal very much, but only until I read that := ins't going to be used for assigning vals. (Initially I assumed := was going to be used both for vals and vars.)

Yes, I treat val a = 7 as assigning val, not as defining it. Why? That's why:

• Primary reason:

  var a = 1
  val b = a
  a = 2
  println(b) // will print `1`, not `2` (unlike it would for `def b = a`)
  

• Secondary reason:

  var a = 1
  val b = a
  b = 2 // this won't work (won't passthrough `2` to `a`)
  

So, from a newbie perspective, val is not a true definition but an assignment. IMHO, if we would introduce :=, we should use it for both vals and vars (and only defs should keep using = then).

(In other words, IMHO the aforementioned reference problem prevents us not only from introducing val a = Var[Int] but also from using different syntax for vals and vars.)

Sorry for a necrocomment.