Sdk: Everything should be an expression

Created on 11 Oct 2011  Â·  10Comments  Â·  Source: dart-lang/sdk

_This issue was originally filed by [email protected]_


Why have statements and expressions when everything could be an expression? They are both special language forms to implement certain features such as conditions or looping, but some of them are chosen to be called statements and are artificially limited as to where they are allowed or that they cannot return values. (Note that many expressions return empty/null values too.) Statements are like expressions with additional restrictions for the heck of it.

A far more powerful, flexible approach is to make everything an expression that may fit anywhere; expressions being sequenced with semicolons in the case you need to evaluate several of them in a row. It does not have to affect the way you write anything with statements; it just supersedes it by allowing you to write more flexible programs. Functional programmers and people coming from similar backgrounds would love this feature. Expressivity matters a lot when writing complex software for many of us, and Dart has a chance to keep a popular, well-known syntax but go a step further (and give yet another reason to switch).

So my suggestion is to transform all statements into expressions returning either nothing or the last evaluated value (which would be useful for if, loops, functions and so on). It would also make the language simpler to define, and the ternary operator would be no longer necessary since there's if.

area-language closed-not-planned type-enhancement

Most helpful comment

_This comment was originally written by [email protected]_


The mainstream conventions you attempt to stick close to were the result of evolution; otherwise Dart would look like Fortran.

You have a chance to take this evolution one step further and get rid of another pointless limitation of traditional languages, and this woudln't encumber those who still want to write code like they write a cake recipe.

Without interesting features like this, programmers like myself won't bother to use Dart: it's more of the same and doesn't scratch our itches. And it's not just programmers who will be unimpressed with Dart: project leaders and CTOs will be, as well — as a matter of fact my boss is. We don't want or need another Java; we want something offering productivity levels and programming models we didn't have in the past, and as it stands, Dart doesn't provide this so it's pages below CoffeeScript in our list of technologies to evaluate and possibly incorporate to our framework and applications.

All 10 comments

_This comment was originally written by [email protected]_


_Removed Type-Defect label._
_Added Type-Enhancement, Area-Language, Triaged labels._

In principle, I am in agreement. That said, it doesn't seem like a great fit for a conservative language like Dart. People wil use it in ways that might confuse the average programmer. But maybe, just maybe, we might be able to do something here.


_Set owner to @gbracha._

_This comment was originally written by jeanhuguesrob...@gmail.com_


CoffeeScript (and Julia) is right on this topic.

I understand the beeing conservative is a marketing thing but I feel like beeing too conservative may be counter productive when trying to sell something... new!

_This comment was originally written by demis.b...@gmail.com_


+1 For having more expressions vs less statements in the language. Allowing a functional style allows terser, more error free code.

_Added apr30-triage label._

_Removed apr30-triage label._

_Added triage1 label._

_Removed triage1 label._
_Added WontFix label._

This isn't realistic in a conservative language like Dart, that seeks to be close to mainstream conventions.

_This comment was originally written by [email protected]_


The mainstream conventions you attempt to stick close to were the result of evolution; otherwise Dart would look like Fortran.

You have a chance to take this evolution one step further and get rid of another pointless limitation of traditional languages, and this woudln't encumber those who still want to write code like they write a cake recipe.

Without interesting features like this, programmers like myself won't bother to use Dart: it's more of the same and doesn't scratch our itches. And it's not just programmers who will be unimpressed with Dart: project leaders and CTOs will be, as well — as a matter of fact my boss is. We don't want or need another Java; we want something offering productivity levels and programming models we didn't have in the past, and as it stands, Dart doesn't provide this so it's pages below CoffeeScript in our list of technologies to evaluate and possibly incorporate to our framework and applications.

Was this page helpful?
0 / 5 - 0 ratings