[dart-misc] Dart really needs syntax imporvements

[Droid Experiments]

First of all, please don't be offended on what I'm talking about. Dart is
the coolest programming language ever. Optional typing, great tools and
great built-in libraries are the coolest things that attracts me and keep
me writing Dart more and more. But when I write Dart; I feel many things
missing. As a modern programming language; there are couple of small things
proposed but never implemented. I want to talk them again.

1. First one is the variable declaration. syntax. There is a need for
better variable declaration syntax that enforce immutability.
five letter keywords like 'final' and 'const' are not good. Most people
won't use it even if most of the variables in their program can be treated
as final.
There should be three letter keyword for each.
for ex:
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should be
val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

and also time inference should be fully supported by the specification and
not the implementation do that.

2. Ranges and Tuples are the missing things:
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or for(var
i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)

3. Switch should be powerful.
- switch should break by default - I think most modern languages go this
way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust, Kotlin
and Swift. It would be very much easy if ranges are supported

4. Privacy and underscores should not be enforced.
- Most dynamic languages do not need privacy and Dart should avoid that at
least by specification and in examples. It should have clear guidelines
about where not to play with ugly underscores. it is ok to denote private
variables with underscore prefix but what about methods. they look ugly.
There should be some kind of annotation or something that generate this
kind of source for you for example:
instead of
void _doSomethingAmazing(){} can be used as

@LibPrivate
void doSomethingAmazing(){} to avoid underscores for methods who dislike
them.

5. Inconstancy in static type system
why there are int and num? to maintain a compatibility with JS or are there
any other reasons? Why String is written with first capital letter but int
is not? In Java, it has reasons for that. You should "draw a line"(I still
remember the discussion before with Gilad.") and the line is to make each
type follow Capsfirst.

The whole community would be very happy and get benefited if Dart team
focus on these little details in 2.0 and making end programmers happy and
more productive.

After all:
“It’s the little details that are vital. Little things make big things
happen.”

['Yegor Jbanov' via Dart Misc]

1. better variable declaration syntax that enforce immutability.

Post by Droid Experiments
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

+1. I'd prefer `let` instead of `val` (`val` looks too much like `var`),
but other than that, I like your proposal. I'd love to see less syntactic
penalty for using immutability. If we want to punish anything, I'd rather
we punished mutables rather than immutables, like Rust does (you have to
use an extra `mut` to make a variable mutable).

Post by Droid Experiments
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or for(var
i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)

+0.5. Tuples would be nice, especially if we also had destructuring.
Ranges? Meh. Could be a utility function `for(var i in range(1, 10))`.

3. Switch should be powerful.

Post by Droid Experiments
- switch should break by default - I think most modern languages go this
way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust, Kotlin
and Swift. It would be very much easy if ranges are supported

+1. Although, I'd like to see Dart have a stronger type system before this
(go strong mode
<https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md>!).
Right now pattern matching will likely need to be done as a runtime
operation.

4. Privacy and underscores should not be enforced.
-1. That's why in dynamic languages every change is an API breaking change,
even if you recommend that people don't use privates. Also, guaranteed
privacy works as a zero-cost abstraction. For example, the compiler can
freely inline a private method, eliminating the cost of a dynamically
dispatched method call. Don't hesitate to break up a long method into
multiple smaller private methods. You will pay no cost for this abstraction.

I actually think of Dart as a *static language* that *pretends* to be
dynamic. It just does it so well! Yes, type *annotations* are optional, but
types themselves are there, inferred and used by the compiler anyway, even
if you annotate things with `dynamic`. The function/method signatures and
class/library shape are all static (no monkey patching allowed). You can
witness it yourself by compiling your app and passing --dump-info to
dart2js. Then open up the dump-info file
in https://dart-lang.github.io/dump-info-visualizer/. It will show
everything the compiler figured out about your program, statically, without
executing any of the program's code (incidentally, this is also why Dart
apps are fast and dart2js is slow). This is one of the coolest things about
the language's design.

5. Inconstancy in static type system

Post by Droid Experiments
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

+1. Although, I think it's a little too late to change this. I wouldn't
mind seeing some future version of Dart introduce breaking changes to fix
these little warts, as long as there's also a tool that can migrate my old
code, at least 90% of it (this worked very well in the early days of Go,
and Swift is still doing this).

[Droid Experiments]

Thanks Yegor for your response.
1. Yes, whatever the community prefer; but Dart should have three letter
appealing keywords for variable declarations instead of boring five letter
keywords that most 'general' dev would not use them.

2. I think most programmers would like to have ranges. There are too much
nonsense parenthesis in for(var i in (1,10)). aren't they? It should be
something like for(var i in 1 to 10) or for(var i in 1...10); simple.
Ranges are important when you have ability for pattern matching in switch
like expressions. Just like switch(value){ case 1 to 10 : doSomething()}

3. Optional type system is great. It is great for prototyping, It is great
for gradually evolving programs. Small compile time in development is
bearable. So, if the pattern matching can take more time at run time for
VM; then there can be small compilation of subtle number of things can take
more time.

4. Yes but most Dart devs would agree at some point that underscores for
method names make them very unreadable.

5. It would be easy to migrate the code if Google give the simple tool to
migrate the old code.

Dart is a great 'general-purpose' programming language; not a Javascript
rival. There is no meant to make it familiar for javascript developers. In
fact; most javascript devs do not need it. I hate the philosophy of making
Dart more appealing to JS or any other programming language developers. It
is perhaps the best language on its own with C like syntax, great optional
type system and powerful libraries and tools. *The truth is that it would
be great if Dart team just focus on end programmer productivity rather than
making it familiar for X language devs or making it only for web; otherwise
this great project would fail one day to convince end programmers to use
Dart.*

I am a not native English speaker. So, apologize if my English is somewhat
bad.

Post by 'Yegor Jbanov' via Dart Misc
1. better variable declaration syntax that enforce immutability.

Post by Droid Experiments
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

+1. I'd prefer `let` instead of `val` (`val` looks too much like `var`),
but other than that, I like your proposal. I'd love to see less syntactic
penalty for using immutability. If we want to punish anything, I'd rather
we punished mutables rather than immutables, like Rust does (you have to
use an extra `mut` to make a variable mutable).

Post by Droid Experiments
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)

+0.5. Tuples would be nice, especially if we also had destructuring.
Ranges? Meh. Could be a utility function `for(var i in range(1, 10))`.
3. Switch should be powerful.

Post by Droid Experiments
- switch should break by default - I think most modern languages go this
way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust, Kotlin
and Swift. It would be very much easy if ranges are supported

+1. Although, I'd like to see Dart have a stronger type system before this
(go strong mode
<https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md>!).
Right now pattern matching will likely need to be done as a runtime
operation.
4. Privacy and underscores should not be enforced.
-1. That's why in dynamic languages every change is an API breaking
change, even if you recommend that people don't use privates. Also,
guaranteed privacy works as a zero-cost abstraction. For example, the
compiler can freely inline a private method, eliminating the cost of a
dynamically dispatched method call. Don't hesitate to break up a long
method into multiple smaller private methods. You will pay no cost for this
abstraction.
I actually think of Dart as a *static language* that *pretends* to be
dynamic. It just does it so well! Yes, type *annotations* are optional,
but types themselves are there, inferred and used by the compiler anyway,
even if you annotate things with `dynamic`. The function/method signatures
and class/library shape are all static (no monkey patching allowed). You
can witness it yourself by compiling your app and passing --dump-info to
dart2js. Then open up the dump-info file in
https://dart-lang.github.io/dump-info-visualizer/. It will show
everything the compiler figured out about your program, statically, without
executing any of the program's code (incidentally, this is also why Dart
apps are fast and dart2js is slow). This is one of the coolest things about
the language's design.
5. Inconstancy in static type system

Post by Droid Experiments
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

+1. Although, I think it's a little too late to change this. I wouldn't
mind seeing some future version of Dart introduce breaking changes to fix
these little warts, as long as there's also a tool that can migrate my old
code, at least 90% of it (this worked very well in the early days of Go,
and Swift is still doing this).

[krupal shah]

+1. There are about two and half years went since Dart 1.0 was announced. I
think Dart team have already been thinking about making it more appealing
and importantly general purpose programming language. We hope that they go
that way for 2.0.

*The truth is that it would be great if Dart team just focus on end
programmer productivity rather than making it familiar for X language devs
or making it only for web; otherwise this great project would fail one day
to convince end programmers to use Dart.*

Post by 'Yegor Jbanov' via Dart Misc
1. better variable declaration syntax that enforce immutability.

Post by Droid Experiments
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

+1. I'd prefer `let` instead of `val` (`val` looks too much like `var`),
but other than that, I like your proposal. I'd love to see less syntactic
penalty for using immutability. If we want to punish anything, I'd rather
we punished mutables rather than immutables, like Rust does (you have to
use an extra `mut` to make a variable mutable).

Post by Droid Experiments
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)

+0.5. Tuples would be nice, especially if we also had destructuring.
Ranges? Meh. Could be a utility function `for(var i in range(1, 10))`.
3. Switch should be powerful.

Post by Droid Experiments
- switch should break by default - I think most modern languages go this
way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust,
Kotlin and Swift. It would be very much easy if ranges are supported

+1. Although, I'd like to see Dart have a stronger type system before
this (go strong mode
<https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md>!).
Right now pattern matching will likely need to be done as a runtime
operation.
4. Privacy and underscores should not be enforced.
-1. That's why in dynamic languages every change is an API breaking
change, even if you recommend that people don't use privates. Also,
guaranteed privacy works as a zero-cost abstraction. For example, the
compiler can freely inline a private method, eliminating the cost of a
dynamically dispatched method call. Don't hesitate to break up a long
method into multiple smaller private methods. You will pay no cost for this
abstraction.
I actually think of Dart as a *static language* that *pretends* to be
dynamic. It just does it so well! Yes, type *annotations* are optional,
but types themselves are there, inferred and used by the compiler anyway,
even if you annotate things with `dynamic`. The function/method signatures
and class/library shape are all static (no monkey patching allowed). You
can witness it yourself by compiling your app and passing --dump-info to
dart2js. Then open up the dump-info file in
https://dart-lang.github.io/dump-info-visualizer/. It will show
everything the compiler figured out about your program, statically, without
executing any of the program's code (incidentally, this is also why Dart
apps are fast and dart2js is slow). This is one of the coolest things about
the language's design.
5. Inconstancy in static type system

Post by Droid Experiments
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

+1. Although, I think it's a little too late to change this. I wouldn't
mind seeing some future version of Dart introduce breaking changes to fix
these little warts, as long as there's also a tool that can migrate my old
code, at least 90% of it (this worked very well in the early days of Go,
and Swift is still doing this).

[lihui]

simply drop dart , replaced it with kotlinjs kotlinvm

Post by krupal shah
+1. There are about two and half years went since Dart 1.0 was announced.
I think Dart team have already been thinking about making it more appealing
and importantly general purpose programming language. We hope that they go
that way for 2.0.

*The truth is that it would be great if Dart team just focus on end
programmer productivity rather than making it familiar for X language devs
or making it only for web; otherwise this great project would fail one day
to convince end programmers to use Dart.*

Post by 'Yegor Jbanov' via Dart Misc
1. better variable declaration syntax that enforce immutability.

Post by Droid Experiments
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

+1. I'd prefer `let` instead of `val` (`val` looks too much like `var`),
but other than that, I like your proposal. I'd love to see less syntactic
penalty for using immutability. If we want to punish anything, I'd rather
we punished mutables rather than immutables, like Rust does (you have to
use an extra `mut` to make a variable mutable).

Post by Droid Experiments
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)

+0.5. Tuples would be nice, especially if we also had destructuring.
Ranges? Meh. Could be a utility function `for(var i in range(1, 10))`.
3. Switch should be powerful.

Post by Droid Experiments
- switch should break by default - I think most modern languages go
this way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust,
Kotlin and Swift. It would be very much easy if ranges are supported

+1. Although, I'd like to see Dart have a stronger type system before
this (go strong mode
<https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md>!).
Right now pattern matching will likely need to be done as a runtime
operation.
4. Privacy and underscores should not be enforced.
-1. That's why in dynamic languages every change is an API breaking
change, even if you recommend that people don't use privates. Also,
guaranteed privacy works as a zero-cost abstraction. For example, the
compiler can freely inline a private method, eliminating the cost of a
dynamically dispatched method call. Don't hesitate to break up a long
method into multiple smaller private methods. You will pay no cost for this
abstraction.
I actually think of Dart as a *static language* that *pretends* to be
dynamic. It just does it so well! Yes, type *annotations* are optional,
but types themselves are there, inferred and used by the compiler anyway,
even if you annotate things with `dynamic`. The function/method signatures
and class/library shape are all static (no monkey patching allowed). You
can witness it yourself by compiling your app and passing --dump-info to
dart2js. Then open up the dump-info file in
https://dart-lang.github.io/dump-info-visualizer/. It will show
everything the compiler figured out about your program, statically, without
executing any of the program's code (incidentally, this is also why Dart
apps are fast and dart2js is slow). This is one of the coolest things about
the language's design.
5. Inconstancy in static type system

Post by Droid Experiments
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

+1. Although, I think it's a little too late to change this. I wouldn't
mind seeing some future version of Dart introduce breaking changes to fix
these little warts, as long as there's also a tool that can migrate my old
code, at least 90% of it (this worked very well in the early days of Go,
and Swift is still doing this).
--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Günter Zöchbauer]

Post by lihui
simply drop dart , replaced it with kotlinjs kotlinvm

Why do you read the Dart group when you prefer Kotlin?

Post by lihui

Post by krupal shah
+1. There are about two and half years went since Dart 1.0 was announced.
I think Dart team have already been thinking about making it more appealing
and importantly general purpose programming language. We hope that they go
that way for 2.0.

*The truth is that it would be great if Dart team just focus on end
programmer productivity rather than making it familiar for X language devs
or making it only for web; otherwise this great project would fail one day
to convince end programmers to use Dart.*

Post by 'Yegor Jbanov' via Dart Misc
1. better variable declaration syntax that enforce immutability.

Post by Droid Experiments
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

+1. I'd prefer `let` instead of `val` (`val` looks too much like
`var`), but other than that, I like your proposal. I'd love to see less
syntactic penalty for using immutability. If we want to punish anything,
I'd rather we punished mutables rather than immutables, like Rust does (you
have to use an extra `mut` to make a variable mutable).

Post by Droid Experiments
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)

+0.5. Tuples would be nice, especially if we also had destructuring.
Ranges? Meh. Could be a utility function `for(var i in range(1, 10))`.
3. Switch should be powerful.

Post by Droid Experiments
- switch should break by default - I think most modern languages go
this way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust,
Kotlin and Swift. It would be very much easy if ranges are supported

+1. Although, I'd like to see Dart have a stronger type system before
this (go strong mode
<https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md>!).
Right now pattern matching will likely need to be done as a runtime
operation.
4. Privacy and underscores should not be enforced.
-1. That's why in dynamic languages every change is an API breaking
change, even if you recommend that people don't use privates. Also,
guaranteed privacy works as a zero-cost abstraction. For example, the
compiler can freely inline a private method, eliminating the cost of a
dynamically dispatched method call. Don't hesitate to break up a long
method into multiple smaller private methods. You will pay no cost for this
abstraction.
I actually think of Dart as a *static language* that *pretends* to be
dynamic. It just does it so well! Yes, type *annotations* are
optional, but types themselves are there, inferred and used by the compiler
anyway, even if you annotate things with `dynamic`. The function/method
signatures and class/library shape are all static (no monkey patching
allowed). You can witness it yourself by compiling your app and passing
--dump-info to dart2js. Then open up the dump-info file in
https://dart-lang.github.io/dump-info-visualizer/. It will show
everything the compiler figured out about your program, statically, without
executing any of the program's code (incidentally, this is also why Dart
apps are fast and dart2js is slow). This is one of the coolest things about
the language's design.
5. Inconstancy in static type system

Post by Droid Experiments
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

+1. Although, I think it's a little too late to change this. I wouldn't
mind seeing some future version of Dart introduce breaking changes to fix
these little warts, as long as there's also a tool that can migrate my old
code, at least 90% of it (this worked very well in the early days of Go,
and Swift is still doing this).
--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[lihui]

I have follow dart from the beginning. the habit is formed. I really used
to like it and still expect some exciting things from here.

in the regard of language design, kotlin is better. but it still lack
async/await/yield (coming soon) and strong support on kotlin js.




圚 2016幎5月9日星期䞀 UTC+8䞋午12:28:17GÃŒnter Zöchbauer写道

Post by Günter Zöchbauer

Post by lihui
simply drop dart , replaced it with kotlinjs kotlinvm

Why do you read the Dart group when you prefer Kotlin?

Post by lihui

Post by krupal shah
+1. There are about two and half years went since Dart 1.0 was
announced. I think Dart team have already been thinking about making it
more appealing and importantly general purpose programming language. We
hope that they go that way for 2.0.

*The truth is that it would be great if Dart team just focus on end
programmer productivity rather than making it familiar for X language devs
or making it only for web; otherwise this great project would fail one day
to convince end programmers to use Dart.*

Post by 'Yegor Jbanov' via Dart Misc
1. better variable declaration syntax that enforce immutability.

Post by Droid Experiments
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

+1. I'd prefer `let` instead of `val` (`val` looks too much like
`var`), but other than that, I like your proposal. I'd love to see less
syntactic penalty for using immutability. If we want to punish anything,
I'd rather we punished mutables rather than immutables, like Rust does (you
have to use an extra `mut` to make a variable mutable).

Post by Droid Experiments
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return
multiple values from a function in one or another way. (take the Kotlin for
example : it has nice data annotation to make small value classes to
eliminate the need for tuples)

+0.5. Tuples would be nice, especially if we also had destructuring.
Ranges? Meh. Could be a utility function `for(var i in range(1, 10))`.
3. Switch should be powerful.

Post by Droid Experiments
- switch should break by default - I think most modern languages go
this way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust,
Kotlin and Swift. It would be very much easy if ranges are supported

+1. Although, I'd like to see Dart have a stronger type system before
this (go strong mode
<https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md>!).
Right now pattern matching will likely need to be done as a runtime
operation.
4. Privacy and underscores should not be enforced.
-1. That's why in dynamic languages every change is an API breaking
change, even if you recommend that people don't use privates. Also,
guaranteed privacy works as a zero-cost abstraction. For example, the
compiler can freely inline a private method, eliminating the cost of a
dynamically dispatched method call. Don't hesitate to break up a long
method into multiple smaller private methods. You will pay no cost for this
abstraction.
I actually think of Dart as a *static language* that *pretends* to be
dynamic. It just does it so well! Yes, type *annotations* are
optional, but types themselves are there, inferred and used by the compiler
anyway, even if you annotate things with `dynamic`. The function/method
signatures and class/library shape are all static (no monkey patching
allowed). You can witness it yourself by compiling your app and passing
--dump-info to dart2js. Then open up the dump-info file in
https://dart-lang.github.io/dump-info-visualizer/. It will show
everything the compiler figured out about your program, statically, without
executing any of the program's code (incidentally, this is also why Dart
apps are fast and dart2js is slow). This is one of the coolest things about
the language's design.
5. Inconstancy in static type system

Post by Droid Experiments
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

+1. Although, I think it's a little too late to change this. I
wouldn't mind seeing some future version of Dart introduce breaking changes
to fix these little warts, as long as there's also a tool that can migrate
my old code, at least 90% of it (this worked very well in the early days of
Go, and Swift is still doing this).
--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send

[Hoo Luu]

This is why we are looking forward to Dart 2.0. Now the burden of
integrating dart VM into chrome has gone,which leaves more room to improve
the language design.

圚 2016幎5月9日星期䞀 UTC+8䞋午1:14:42lihui写道

Post by lihui
in the regard of language design, kotlin is better. but it still lack
async/await/yield (coming soon) and strong support on kotlin js.
圚 2016幎5月9日星期䞀 UTC+8䞋午12:28:17GÃŒnter Zöchbauer写道

Post by Günter Zöchbauer

Post by lihui
simply drop dart , replaced it with kotlinjs kotlinvm

Why do you read the Dart group when you prefer Kotlin?

Post by lihui

Post by krupal shah
+1. There are about two and half years went since Dart 1.0 was
announced. I think Dart team have already been thinking about making it
more appealing and importantly general purpose programming language. We
hope that they go that way for 2.0.

*The truth is that it would be great if Dart team just focus on end
programmer productivity rather than making it familiar for X language devs
or making it only for web; otherwise this great project would fail one day
to convince end programmers to use Dart.*

Post by 'Yegor Jbanov' via Dart Misc
1. better variable declaration syntax that enforce immutability.

Post by Droid Experiments
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

+1. I'd prefer `let` instead of `val` (`val` looks too much like
`var`), but other than that, I like your proposal. I'd love to see less
syntactic penalty for using immutability. If we want to punish anything,
I'd rather we punished mutables rather than immutables, like Rust does (you
have to use an extra `mut` to make a variable mutable).

Post by Droid Experiments
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return
multiple values from a function in one or another way. (take the Kotlin for
example : it has nice data annotation to make small value classes to
eliminate the need for tuples)

+0.5. Tuples would be nice, especially if we also had destructuring.
Ranges? Meh. Could be a utility function `for(var i in range(1, 10))`.
3. Switch should be powerful.

Post by Droid Experiments
- switch should break by default - I think most modern languages go
this way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust,
Kotlin and Swift. It would be very much easy if ranges are supported

+1. Although, I'd like to see Dart have a stronger type system before
this (go strong mode
<https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md>!).
Right now pattern matching will likely need to be done as a runtime
operation.
4. Privacy and underscores should not be enforced.
-1. That's why in dynamic languages every change is an API breaking
change, even if you recommend that people don't use privates. Also,
guaranteed privacy works as a zero-cost abstraction. For example, the
compiler can freely inline a private method, eliminating the cost of a
dynamically dispatched method call. Don't hesitate to break up a long
method into multiple smaller private methods. You will pay no cost for this
abstraction.
I actually think of Dart as a *static language* that *pretends* to
be dynamic. It just does it so well! Yes, type *annotations* are
optional, but types themselves are there, inferred and used by the compiler
anyway, even if you annotate things with `dynamic`. The function/method
signatures and class/library shape are all static (no monkey patching
allowed). You can witness it yourself by compiling your app and passing
--dump-info to dart2js. Then open up the dump-info file in
https://dart-lang.github.io/dump-info-visualizer/. It will show
everything the compiler figured out about your program, statically, without
executing any of the program's code (incidentally, this is also why Dart
apps are fast and dart2js is slow). This is one of the coolest things about
the language's design.
5. Inconstancy in static type system

Post by Droid Experiments
why there are int and num? to maintain a compatibility with JS or
are there any other reasons? Why String is written with first capital
letter but int is not? In Java, it has reasons for that. You should "draw a
line" and the line is to make each type follow Capsfirst.

+1. Although, I think it's a little too late to change this. I
wouldn't mind seeing some future version of Dart introduce breaking changes
to fix these little warts, as long as there's also a tool that can migrate
my old code, at least 90% of it (this worked very well in the early days of
Go, and Swift is still doing this).
--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send

[Ahmet A. Akın]

I had hopes that some Dart devs, behind the curtain are making some awesome
syntax/lib changes and they will suddenly come back with s "surprise!!"..
But knowing that making changes even for the semi-established languages
like Dart is very hard, my hopes has been faded. Then I came to
realization that probably my expectations were just not that awesome or
important after all.

Post by Hoo Luu
This is why we are looking forward to Dart 2.0. Now the burden of
integrating dart VM into chrome has gone,which leaves more room to improve
the language design.
圚 2016幎5月9日星期䞀 UTC+8䞋午1:14:42lihui写道

Post by lihui
in the regard of language design, kotlin is better. but it still lack
async/await/yield (coming soon) and strong support on kotlin js.

[krupal shah]

Something is coming
<https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md> for
sure. Don't loose hope!

Post by Ahmet A. Akın
I had hopes that some Dart devs, behind the curtain are making some
awesome syntax/lib changes and they will suddenly come back with s
"surprise!!".. But knowing that making changes even for the
semi-established languages like Dart is very hard, my hopes has been
faded. Then I came to realization that probably my expectations were just
not that awesome or important after all.

Post by Hoo Luu
This is why we are looking forward to Dart 2.0. Now the burden of
integrating dart VM into chrome has gone,which leaves more room to improve
the language design.
圚 2016幎5月9日星期䞀 UTC+8䞋午1:14:42lihui写道

Post by lihui
in the regard of language design, kotlin is better. but it still lack
async/await/yield (coming soon) and strong support on kotlin js.

[Droid Experiments]

Any one can have interest in learning multiple good programming languages.
Kotlin is different but from the project perspective; Jetbrains did a
better job than Google did for the Dart.

Post by Günter Zöchbauer

Post by lihui
simply drop dart , replaced it with kotlinjs kotlinvm

Why do you read the Dart group when you prefer Kotlin?

Post by lihui

Post by krupal shah
+1. There are about two and half years went since Dart 1.0 was
announced. I think Dart team have already been thinking about making it
more appealing and importantly general purpose programming language. We
hope that they go that way for 2.0.

*The truth is that it would be great if Dart team just focus on end
programmer productivity rather than making it familiar for X language devs
or making it only for web; otherwise this great project would fail one day
to convince end programmers to use Dart.*

Post by 'Yegor Jbanov' via Dart Misc
1. better variable declaration syntax that enforce immutability.

Post by Droid Experiments
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

+1. I'd prefer `let` instead of `val` (`val` looks too much like
`var`), but other than that, I like your proposal. I'd love to see less
syntactic penalty for using immutability. If we want to punish anything,
I'd rather we punished mutables rather than immutables, like Rust does (you
have to use an extra `mut` to make a variable mutable).

Post by Droid Experiments
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return
multiple values from a function in one or another way. (take the Kotlin for
example : it has nice data annotation to make small value classes to
eliminate the need for tuples)

+0.5. Tuples would be nice, especially if we also had destructuring.
Ranges? Meh. Could be a utility function `for(var i in range(1, 10))`.
3. Switch should be powerful.

Post by Droid Experiments
- switch should break by default - I think most modern languages go
this way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust,
Kotlin and Swift. It would be very much easy if ranges are supported

+1. Although, I'd like to see Dart have a stronger type system before
this (go strong mode
<https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md>!).
Right now pattern matching will likely need to be done as a runtime
operation.
4. Privacy and underscores should not be enforced.
-1. That's why in dynamic languages every change is an API breaking
change, even if you recommend that people don't use privates. Also,
guaranteed privacy works as a zero-cost abstraction. For example, the
compiler can freely inline a private method, eliminating the cost of a
dynamically dispatched method call. Don't hesitate to break up a long
method into multiple smaller private methods. You will pay no cost for this
abstraction.
I actually think of Dart as a *static language* that *pretends* to be
dynamic. It just does it so well! Yes, type *annotations* are
optional, but types themselves are there, inferred and used by the compiler
anyway, even if you annotate things with `dynamic`. The function/method
signatures and class/library shape are all static (no monkey patching
allowed). You can witness it yourself by compiling your app and passing
--dump-info to dart2js. Then open up the dump-info file in
https://dart-lang.github.io/dump-info-visualizer/. It will show
everything the compiler figured out about your program, statically, without
executing any of the program's code (incidentally, this is also why Dart
apps are fast and dart2js is slow). This is one of the coolest things about
the language's design.
5. Inconstancy in static type system

Post by Droid Experiments
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

+1. Although, I think it's a little too late to change this. I
wouldn't mind seeing some future version of Dart introduce breaking changes
to fix these little warts, as long as there's also a tool that can migrate
my old code, at least 90% of it (this worked very well in the early days of
Go, and Swift is still doing this).
--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send

[Kévin Platel]

Kotlin don't have the same historic as Dart.

- Kotlin was design day one to be fully interoperable with Java, Dart was
design to be easy to use for Java and JS developer
- Dart was historically design to be "interoperable" (not sure of the terms
here) with chrome, to be maybe used aside V8, Kotlin choose to compile to
JS only
- ....

You can't compare so easily Kotlin and Dart, the 2 programming language
wasn't design with the same objective in the first place.

Jetbrains did a good job in regards of their objective, as the Dart Team
for me.

Post by Droid Experiments
Any one can have interest in learning multiple good programming languages.
Kotlin is different but from the project perspective; Jetbrains did a
better job than Google did for the Dart.

Post by Günter Zöchbauer

Post by lihui
simply drop dart , replaced it with kotlinjs kotlinvm

Why do you read the Dart group when you prefer Kotlin?

Post by lihui

Post by krupal shah
+1. There are about two and half years went since Dart 1.0 was
announced. I think Dart team have already been thinking about making it
more appealing and importantly general purpose programming language. We
hope that they go that way for 2.0.

*The truth is that it would be great if Dart team just focus on end
programmer productivity rather than making it familiar for X language devs
or making it only for web; otherwise this great project would fail one day
to convince end programmers to use Dart.*

Post by 'Yegor Jbanov' via Dart Misc
1. better variable declaration syntax that enforce immutability.

Post by Droid Experiments
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

+1. I'd prefer `let` instead of `val` (`val` looks too much like
`var`), but other than that, I like your proposal. I'd love to see less
syntactic penalty for using immutability. If we want to punish anything,
I'd rather we punished mutables rather than immutables, like Rust does (you
have to use an extra `mut` to make a variable mutable).

Post by Droid Experiments
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return
multiple values from a function in one or another way. (take the Kotlin for
example : it has nice data annotation to make small value classes to
eliminate the need for tuples)

+0.5. Tuples would be nice, especially if we also had destructuring.
Ranges? Meh. Could be a utility function `for(var i in range(1, 10))`.
3. Switch should be powerful.

Post by Droid Experiments
- switch should break by default - I think most modern languages go
this way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust,
Kotlin and Swift. It would be very much easy if ranges are supported

+1. Although, I'd like to see Dart have a stronger type system before
this (go strong mode
<https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md>!).
Right now pattern matching will likely need to be done as a runtime
operation.
4. Privacy and underscores should not be enforced.
-1. That's why in dynamic languages every change is an API breaking
change, even if you recommend that people don't use privates. Also,
guaranteed privacy works as a zero-cost abstraction. For example, the
compiler can freely inline a private method, eliminating the cost of a
dynamically dispatched method call. Don't hesitate to break up a long
method into multiple smaller private methods. You will pay no cost for this
abstraction.
I actually think of Dart as a *static language* that *pretends* to
be dynamic. It just does it so well! Yes, type *annotations* are
optional, but types themselves are there, inferred and used by the compiler
anyway, even if you annotate things with `dynamic`. The function/method
signatures and class/library shape are all static (no monkey patching
allowed). You can witness it yourself by compiling your app and passing
--dump-info to dart2js. Then open up the dump-info file in
https://dart-lang.github.io/dump-info-visualizer/. It will show
everything the compiler figured out about your program, statically, without
executing any of the program's code (incidentally, this is also why Dart
apps are fast and dart2js is slow). This is one of the coolest things about
the language's design.
5. Inconstancy in static type system

Post by Droid Experiments
why there are int and num? to maintain a compatibility with JS or
are there any other reasons? Why String is written with first capital
letter but int is not? In Java, it has reasons for that. You should "draw a
line" and the line is to make each type follow Capsfirst.

+1. Although, I think it's a little too late to change this. I
wouldn't mind seeing some future version of Dart introduce breaking changes
to fix these little warts, as long as there's also a tool that can migrate
my old code, at least 90% of it (this worked very well in the early days of
Go, and Swift is still doing this).
--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
PLATEL Kévin
Android Developper at Netatmo

[Smit Joshi]

Apart from these great syntax improvements; there would be nice if Dart
adds improved concurrency support like Go.

Post by 'Yegor Jbanov' via Dart Misc
1. better variable declaration syntax that enforce immutability.

Post by Droid Experiments
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

+1. I'd prefer `let` instead of `val` (`val` looks too much like `var`),
but other than that, I like your proposal. I'd love to see less syntactic
penalty for using immutability. If we want to punish anything, I'd rather
we punished mutables rather than immutables, like Rust does (you have to
use an extra `mut` to make a variable mutable).

Post by Droid Experiments
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)

+0.5. Tuples would be nice, especially if we also had destructuring.
Ranges? Meh. Could be a utility function `for(var i in range(1, 10))`.
3. Switch should be powerful.

Post by Droid Experiments
- switch should break by default - I think most modern languages go this
way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust, Kotlin
and Swift. It would be very much easy if ranges are supported

+1. Although, I'd like to see Dart have a stronger type system before this
(go strong mode
<https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md>!).
Right now pattern matching will likely need to be done as a runtime
operation.
4. Privacy and underscores should not be enforced.
-1. That's why in dynamic languages every change is an API breaking
change, even if you recommend that people don't use privates. Also,
guaranteed privacy works as a zero-cost abstraction. For example, the
compiler can freely inline a private method, eliminating the cost of a
dynamically dispatched method call. Don't hesitate to break up a long
method into multiple smaller private methods. You will pay no cost for this
abstraction.
I actually think of Dart as a *static language* that *pretends* to be
dynamic. It just does it so well! Yes, type *annotations* are optional,
but types themselves are there, inferred and used by the compiler anyway,
even if you annotate things with `dynamic`. The function/method signatures
and class/library shape are all static (no monkey patching allowed). You
can witness it yourself by compiling your app and passing --dump-info to
dart2js. Then open up the dump-info file in
https://dart-lang.github.io/dump-info-visualizer/. It will show
everything the compiler figured out about your program, statically, without
executing any of the program's code (incidentally, this is also why Dart
apps are fast and dart2js is slow). This is one of the coolest things about
the language's design.
5. Inconstancy in static type system

Post by Droid Experiments
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

+1. Although, I think it's a little too late to change this. I wouldn't
mind seeing some future version of Dart introduce breaking changes to fix
these little warts, as long as there's also a tool that can migrate my old
code, at least 90% of it (this worked very well in the early days of Go,
and Swift is still doing this).

[Jan Mostert]

I'm using both Kotlin and Dart ...

Kotlin is a much easier transition from the Java world considering you can
mix Java and Kotlin with great / near perfect interop which means I can
easily switch and continue to use my favorite libraries and database
drivers with no issues and no longer have all the Java boilerplate.
Dart shines as a an alternative to JavaScript and it has Angular2 support.
I'm not sure how mature the KotlinJS implementation is; as far as I know,
they put it on hold until V1 of Kotlin was available which happened very
recently and considering they had to fix bugs in V1, I'm not sure KotlinJS
is getting much love at the moment.
With ScalaJS, there used to be long compile times in order to make use of
the generated JS until they switched to incremental compiles and only a
subset of the language could be used to compile to JS, Kotlin will probably
be in the same boat for quite a while.

With Dart, the majority of the language can be cross-compiled to JS and the
"pub serve" experience is simply superior to the ScalaJS incremental
compiler experience.

Use the right tool for the job! Dart is currently the superior choice for
front-end development and Kotlin the better choice in a Java environment if
you need interop with Java and different databases.

Looking forward to 2.0 !!!

Post by Smit Joshi
Apart from these great syntax improvements; there would be nice if Dart
adds improved concurrency support like Go.

Post by 'Yegor Jbanov' via Dart Misc
1. better variable declaration syntax that enforce immutability.

Post by Droid Experiments
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

+1. I'd prefer `let` instead of `val` (`val` looks too much like `var`),
but other than that, I like your proposal. I'd love to see less syntactic
penalty for using immutability. If we want to punish anything, I'd rather
we punished mutables rather than immutables, like Rust does (you have to
use an extra `mut` to make a variable mutable).

Post by Droid Experiments
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)

+0.5. Tuples would be nice, especially if we also had destructuring.
Ranges? Meh. Could be a utility function `for(var i in range(1, 10))`.
3. Switch should be powerful.

Post by Droid Experiments
- switch should break by default - I think most modern languages go this
way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust,
Kotlin and Swift. It would be very much easy if ranges are supported

+1. Although, I'd like to see Dart have a stronger type system before
this (go strong mode
<https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md>!).
Right now pattern matching will likely need to be done as a runtime
operation.
4. Privacy and underscores should not be enforced.
-1. That's why in dynamic languages every change is an API breaking
change, even if you recommend that people don't use privates. Also,
guaranteed privacy works as a zero-cost abstraction. For example, the
compiler can freely inline a private method, eliminating the cost of a
dynamically dispatched method call. Don't hesitate to break up a long
method into multiple smaller private methods. You will pay no cost for this
abstraction.
I actually think of Dart as a *static language* that *pretends* to be
dynamic. It just does it so well! Yes, type *annotations* are optional,
but types themselves are there, inferred and used by the compiler anyway,
even if you annotate things with `dynamic`. The function/method signatures
and class/library shape are all static (no monkey patching allowed). You
can witness it yourself by compiling your app and passing --dump-info to
dart2js. Then open up the dump-info file in
https://dart-lang.github.io/dump-info-visualizer/. It will show
everything the compiler figured out about your program, statically, without
executing any of the program's code (incidentally, this is also why Dart
apps are fast and dart2js is slow). This is one of the coolest things about
the language's design.
5. Inconstancy in static type system

Post by Droid Experiments
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

+1. Although, I think it's a little too late to change this. I wouldn't
mind seeing some future version of Dart introduce breaking changes to fix
these little warts, as long as there's also a tool that can migrate my old
code, at least 90% of it (this worked very well in the early days of Go,
and Swift is still doing this).
--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[lihui]

what i mean is to use syntax of kotlin as dart2.0.
google has much more resource than jetbrain.

圚 2016幎5月9日星期䞀 UTC+8䞋午2:03:37Jan Vladimir Mostert写道

Post by Jan Mostert
I'm using both Kotlin and Dart ...
Kotlin is a much easier transition from the Java world considering you can
mix Java and Kotlin with great / near perfect interop which means I can
easily switch and continue to use my favorite libraries and database
drivers with no issues and no longer have all the Java boilerplate.
Dart shines as a an alternative to JavaScript and it has Angular2 support.
I'm not sure how mature the KotlinJS implementation is; as far as I know,
they put it on hold until V1 of Kotlin was available which happened very
recently and considering they had to fix bugs in V1, I'm not sure KotlinJS
is getting much love at the moment.
With ScalaJS, there used to be long compile times in order to make use of
the generated JS until they switched to incremental compiles and only a
subset of the language could be used to compile to JS, Kotlin will probably
be in the same boat for quite a while.
With Dart, the majority of the language can be cross-compiled to JS and
the "pub serve" experience is simply superior to the ScalaJS incremental
compiler experience.
Use the right tool for the job! Dart is currently the superior choice for
front-end development and Kotlin the better choice in a Java environment if
you need interop with Java and different databases.
Looking forward to 2.0 !!!

Post by Smit Joshi
Apart from these great syntax improvements; there would be nice if Dart
adds improved concurrency support like Go.

Post by 'Yegor Jbanov' via Dart Misc
1. better variable declaration syntax that enforce immutability.

Post by Droid Experiments
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

+1. I'd prefer `let` instead of `val` (`val` looks too much like `var`),
but other than that, I like your proposal. I'd love to see less syntactic
penalty for using immutability. If we want to punish anything, I'd rather
we punished mutables rather than immutables, like Rust does (you have to
use an extra `mut` to make a variable mutable).

Post by Droid Experiments
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)

+0.5. Tuples would be nice, especially if we also had destructuring.
Ranges? Meh. Could be a utility function `for(var i in range(1, 10))`.
3. Switch should be powerful.

Post by Droid Experiments
- switch should break by default - I think most modern languages go
this way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust,
Kotlin and Swift. It would be very much easy if ranges are supported

+1. Although, I'd like to see Dart have a stronger type system before
this (go strong mode
<https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md>!).
Right now pattern matching will likely need to be done as a runtime
operation.
4. Privacy and underscores should not be enforced.
-1. That's why in dynamic languages every change is an API breaking
change, even if you recommend that people don't use privates. Also,
guaranteed privacy works as a zero-cost abstraction. For example, the
compiler can freely inline a private method, eliminating the cost of a
dynamically dispatched method call. Don't hesitate to break up a long
method into multiple smaller private methods. You will pay no cost for this
abstraction.
I actually think of Dart as a *static language* that *pretends* to be
dynamic. It just does it so well! Yes, type *annotations* are optional,
but types themselves are there, inferred and used by the compiler anyway,
even if you annotate things with `dynamic`. The function/method signatures
and class/library shape are all static (no monkey patching allowed). You
can witness it yourself by compiling your app and passing --dump-info to
dart2js. Then open up the dump-info file in
https://dart-lang.github.io/dump-info-visualizer/. It will show
everything the compiler figured out about your program, statically, without
executing any of the program's code (incidentally, this is also why Dart
apps are fast and dart2js is slow). This is one of the coolest things about
the language's design.
5. Inconstancy in static type system

Post by Droid Experiments
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

+1. Although, I think it's a little too late to change this. I wouldn't
mind seeing some future version of Dart introduce breaking changes to fix
these little warts, as long as there's also a tool that can migrate my old
code, at least 90% of it (this worked very well in the early days of Go,
and Swift is still doing this).
--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Jan Mostert]

Kotlin does have some nice features

when (value) {
1 -> doSomething()
is Long -> doSomethingElse()
else -> doElse()
}

Ranges in Kotlin are nice, it's missing decrementing ranges though.

Nothing can be null unless given permission to be null, so the null safety
of Kotlin is great. I think there were talks about it for Dart2 ?

Kotlin is missing the .. feature; every language should have such a feature!

String templates in both Dart and Kotlin are great!

Kotlin: Params in functions are by default final and all variables are
either var / val which means it's very easy to just use val everywhere
forcing everything to final and then simply switch to var if you need them
non-final.
If Dart makes the default behaviour final and then forces you to use var to
declare it as non-final, that would be great - that would probably require
a different typing style, "var int k = 3" would probably look strange
compared to "var:int k=3" or "var k:int = 3". The RHS types I'm still
getting used to, it feels strange after doing LHS all my life.

Reified types on both are awesome!

Dart has the better operator overloading syntax!

Kotlin has some nice labels you can use with break to jump to a label -
although not great style to use, it can be useful when implementing state
machines.

I can see many similarities between the two, both can probably copy some
features from the other.

Post by lihui
what i mean is to use syntax of kotlin as dart2.0.
google has much more resource than jetbrain.
圚 2016幎5月9日星期䞀 UTC+8䞋午2:03:37Jan Vladimir Mostert写道

Post by Jan Mostert
I'm using both Kotlin and Dart ...
Kotlin is a much easier transition from the Java world considering you
can mix Java and Kotlin with great / near perfect interop which means I can
easily switch and continue to use my favorite libraries and database
drivers with no issues and no longer have all the Java boilerplate.
Dart shines as a an alternative to JavaScript and it has Angular2
support. I'm not sure how mature the KotlinJS implementation is; as far as
I know, they put it on hold until V1 of Kotlin was available which happened
very recently and considering they had to fix bugs in V1, I'm not sure
KotlinJS is getting much love at the moment.
With ScalaJS, there used to be long compile times in order to make use of
the generated JS until they switched to incremental compiles and only a
subset of the language could be used to compile to JS, Kotlin will probably
be in the same boat for quite a while.
With Dart, the majority of the language can be cross-compiled to JS and
the "pub serve" experience is simply superior to the ScalaJS incremental
compiler experience.
Use the right tool for the job! Dart is currently the superior choice for
front-end development and Kotlin the better choice in a Java environment if
you need interop with Java and different databases.
Looking forward to 2.0 !!!

Apart from these great syntax improvements; there would be nice if Dart

Post by Jan Mostert

Post by Smit Joshi
adds improved concurrency support like Go.

Post by 'Yegor Jbanov' via Dart Misc
1. better variable declaration syntax that enforce immutability.

Post by Droid Experiments
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

+1. I'd prefer `let` instead of `val` (`val` looks too much like
`var`), but other than that, I like your proposal. I'd love to see less
syntactic penalty for using immutability. If we want to punish anything,
I'd rather we punished mutables rather than immutables, like Rust does (you
have to use an extra `mut` to make a variable mutable).

Post by Droid Experiments
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)

+0.5. Tuples would be nice, especially if we also had destructuring.
Ranges? Meh. Could be a utility function `for(var i in range(1, 10))`.
3. Switch should be powerful.

Post by Droid Experiments
- switch should break by default - I think most modern languages go
this way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust,
Kotlin and Swift. It would be very much easy if ranges are supported

+1. Although, I'd like to see Dart have a stronger type system before
this (go strong mode
<https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md>!).
Right now pattern matching will likely need to be done as a runtime
operation.
4. Privacy and underscores should not be enforced.
-1. That's why in dynamic languages every change is an API breaking
change, even if you recommend that people don't use privates. Also,
guaranteed privacy works as a zero-cost abstraction. For example, the
compiler can freely inline a private method, eliminating the cost of a
dynamically dispatched method call. Don't hesitate to break up a long
method into multiple smaller private methods. You will pay no cost for this
abstraction.
I actually think of Dart as a *static language* that *pretends* to be
dynamic. It just does it so well! Yes, type *annotations* are
optional, but types themselves are there, inferred and used by the compiler
anyway, even if you annotate things with `dynamic`. The function/method
signatures and class/library shape are all static (no monkey patching
allowed). You can witness it yourself by compiling your app and passing
--dump-info to dart2js. Then open up the dump-info file in
https://dart-lang.github.io/dump-info-visualizer/. It will show
everything the compiler figured out about your program, statically, without
executing any of the program's code (incidentally, this is also why Dart
apps are fast and dart2js is slow). This is one of the coolest things about
the language's design.
5. Inconstancy in static type system

Post by Droid Experiments
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

+1. Although, I think it's a little too late to change this. I wouldn't
mind seeing some future version of Dart introduce breaking changes to fix
these little warts, as long as there's also a tool that can migrate my old
code, at least 90% of it (this worked very well in the early days of Go,
and Swift is still doing this).
--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.

To unsubscribe from this group and stop receiving emails from it, send an
--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Günter Zöchbauer]

Post by Droid Experiments
First of all, please don't be offended on what I'm talking about. Dart is
the coolest programming language ever. Optional typing, great tools and
great built-in libraries are the coolest things that attracts me and keep
me writing Dart more and more. But when I write Dart; I feel many things
missing. As a modern programming language; there are couple of small things
proposed but never implemented. I want to talk them again.
1. First one is the variable declaration. syntax. There is a need for
better variable declaration syntax that enforce immutability.
five letter keywords like 'final' and 'const' are not good. Most people
won't use it even if most of the variables in their program can be treated
as final.
There should be three letter keyword for each.
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

I prefer "final by default" without an additional "final", "val", "let", ...
Besides that I don't see a need for change. Maybe dropping const entirely
if feasible.
There were discussions about both, no idea if we will get it though

Post by Droid Experiments
and also time inference should be fully supported by the specification and
not the implementation do that.
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or for(var
i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)

Would be nice.

Post by Droid Experiments
3. Switch should be powerful.
- switch should break by default - I think most modern languages go this
way. Showing a error for break is nice but annoying.

This was done to not surprise developers coming from other languages AFAIR,
I never saw any value in this.

Post by Droid Experiments
- switch statement should support full pattern matching like Rust, Kotlin
and Swift. It would be very much easy if ranges are supported
no opinion
4. Privacy and underscores should not be enforced.
- Most dynamic languages do not need privacy and Dart should avoid that at
least by specification and in examples. It should have clear guidelines
about where not to play with ugly underscores. it is ok to denote private
variables with underscore prefix but what about methods. they look ugly.
There should be some kind of annotation or something that generate this
instead of
void _doSomethingAmazing(){} can be used as
@LibPrivate
void doSomethingAmazing(){} to avoid underscores for methods who dislike
them.

Underscore for privacy should definitely stay as it is. I like it a lot.

Post by Droid Experiments
5. Inconstancy in static type system
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

Agree.

[Denis Albuquerque]

+1 "final by default", var for mutable.

+1 stick with underscore for privacy. Using underscore allow us to quickly
identify if the function is private without need to check its declaration.
-1 for using annotation for privacy.

+1 tuples support.
I realy like the way python allow us to use tuples to return multiple
values and assign the values to variables. e.g.: (valA, valB) =
functionThatReturnTuple()

+1 syntactic suggar for ranges and list/tuples slicing.
e.g: 1..x, list[start:end] , list[start:end:step], list[start:], list[:end]

+1 for pattern matching and break as default in switch statements.

+0 Type declaration in RHS would be interesting.

As far as I can remember of Dart Roadmap presented on last year Dart Dev
Summit, Dart 2.0 should be announced this year. IÂŽm waiting for the AHA
moment.

Post by Günter Zöchbauer

Post by Droid Experiments
First of all, please don't be offended on what I'm talking about. Dart is
the coolest programming language ever. Optional typing, great tools and
great built-in libraries are the coolest things that attracts me and keep
me writing Dart more and more. But when I write Dart; I feel many things
missing. As a modern programming language; there are couple of small things
proposed but never implemented. I want to talk them again.
1. First one is the variable declaration. syntax. There is a need for
better variable declaration syntax that enforce immutability.
five letter keywords like 'final' and 'const' are not good. Most people
won't use it even if most of the variables in their program can be treated
as final.
There should be three letter keyword for each.
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];

I prefer "final by default" without an additional "final", "val", "let", ...
Besides that I don't see a need for change. Maybe dropping const entirely
if feasible.
There were discussions about both, no idea if we will get it though

Post by Droid Experiments
and also time inference should be fully supported by the specification
and not the implementation do that.
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)

Would be nice.

Post by Droid Experiments
3. Switch should be powerful.
- switch should break by default - I think most modern languages go this
way. Showing a error for break is nice but annoying.

This was done to not surprise developers coming from other languages
AFAIR, I never saw any value in this.

Post by Droid Experiments
- switch statement should support full pattern matching like Rust, Kotlin
and Swift. It would be very much easy if ranges are supported
no opinion
4. Privacy and underscores should not be enforced.
- Most dynamic languages do not need privacy and Dart should avoid that
at least by specification and in examples. It should have clear guidelines
about where not to play with ugly underscores. it is ok to denote private
variables with underscore prefix but what about methods. they look ugly.
There should be some kind of annotation or something that generate this
instead of
void _doSomethingAmazing(){} can be used as
@LibPrivate
void doSomethingAmazing(){} to avoid underscores for methods who dislike
them.

Underscore for privacy should definitely stay as it is. I like it a lot.

Post by Droid Experiments
5. Inconstancy in static type system
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

Agree.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Milan Zimmermann]

My largest plus would be for an item that is not on this list :)

"Make named parameters required" (do not allow unnamed, as a default or
otherwise).

I realize it may be too late in the life of a language for a change like
this. But, well I just feel, for multiple reasons, primary being that code
is read so much more often then written, languages should enforce it. I
had a whole list of +-0s for this thread but in the end, I realized my
favorite is not on the list :(

Post by Droid Experiments
First of all, please don't be offended on what I'm talking about. Dart is
the coolest programming language ever. Optional typing, great tools and
great built-in libraries are the coolest things that attracts me and keep
me writing Dart more and more. But when I write Dart; I feel many things
missing. As a modern programming language; there are couple of small things
proposed but never implemented. I want to talk them again.
1. First one is the variable declaration. syntax. There is a need for
better variable declaration syntax that enforce immutability.
five letter keywords like 'final' and 'const' are not good. Most people
won't use it even if most of the variables in their program can be treated
as final.
There should be three letter keyword for each.
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];
and also time inference should be fully supported by the specification and
not the implementation do that.
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or for(var
i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)
3. Switch should be powerful.
- switch should break by default - I think most modern languages go this
way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust, Kotlin
and Swift. It would be very much easy if ranges are supported
4. Privacy and underscores should not be enforced.
- Most dynamic languages do not need privacy and Dart should avoid that at
least by specification and in examples. It should have clear guidelines
about where not to play with ugly underscores. it is ok to denote private
variables with underscore prefix but what about methods. they look ugly.
There should be some kind of annotation or something that generate this
instead of
void _doSomethingAmazing(){} can be used as
@LibPrivate
void doSomethingAmazing(){} to avoid underscores for methods who dislike
them.
5. Inconstancy in static type system
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

[Benjamin Strauß]

If you go that far you could make one step further and switch to smalltalk
infix notation. ;)

Post by Milan Zimmermann
My largest plus would be for an item that is not on this list :)
"Make named parameters required" (do not allow unnamed, as a default or
otherwise).
I realize it may be too late in the life of a language for a change like
this. But, well I just feel, for multiple reasons, primary being that code
is read so much more often then written, languages should enforce it. I
had a whole list of +-0s for this thread but in the end, I realized my
favorite is not on the list :(

Post by Droid Experiments
First of all, please don't be offended on what I'm talking about. Dart is
the coolest programming language ever. Optional typing, great tools and
great built-in libraries are the coolest things that attracts me and keep
me writing Dart more and more. But when I write Dart; I feel many things
missing. As a modern programming language; there are couple of small things
proposed but never implemented. I want to talk them again.
1. First one is the variable declaration. syntax. There is a need for
better variable declaration syntax that enforce immutability.
five letter keywords like 'final' and 'const' are not good. Most people
won't use it even if most of the variables in their program can be treated
as final.
There should be three letter keyword for each.
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];
and also time inference should be fully supported by the specification
and not the implementation do that.
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)
3. Switch should be powerful.
- switch should break by default - I think most modern languages go this
way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust, Kotlin
and Swift. It would be very much easy if ranges are supported
4. Privacy and underscores should not be enforced.
- Most dynamic languages do not need privacy and Dart should avoid that
at least by specification and in examples. It should have clear guidelines
about where not to play with ugly underscores. it is ok to denote private
variables with underscore prefix but what about methods. they look ugly.
There should be some kind of annotation or something that generate this
instead of
void _doSomethingAmazing(){} can be used as
@LibPrivate
void doSomethingAmazing(){} to avoid underscores for methods who dislike
them.
5. Inconstancy in static type system
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

[krupal shah]

It would be nice if Dart becomes more like small talk rather than being a
blend of Java and javascript. I would love if Dart 2.0 becomes more like a
blend of Scala and Go - Innovative, functional and still fun.

Post by Benjamin Strauß
If you go that far you could make one step further and switch to smalltalk
infix notation. ;)

Post by Milan Zimmermann
My largest plus would be for an item that is not on this list :)
"Make named parameters required" (do not allow unnamed, as a default or
otherwise).
I realize it may be too late in the life of a language for a change like
this. But, well I just feel, for multiple reasons, primary being that code
is read so much more often then written, languages should enforce it. I
had a whole list of +-0s for this thread but in the end, I realized my
favorite is not on the list :(

Post by Droid Experiments
First of all, please don't be offended on what I'm talking about. Dart
is the coolest programming language ever. Optional typing, great tools and
great built-in libraries are the coolest things that attracts me and keep
me writing Dart more and more. But when I write Dart; I feel many things
missing. As a modern programming language; there are couple of small things
proposed but never implemented. I want to talk them again.
1. First one is the variable declaration. syntax. There is a need for
better variable declaration syntax that enforce immutability.
five letter keywords like 'final' and 'const' are not good. Most people
won't use it even if most of the variables in their program can be treated
as final.
There should be three letter keyword for each.
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];
and also time inference should be fully supported by the specification
and not the implementation do that.
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)
3. Switch should be powerful.
- switch should break by default - I think most modern languages go this
way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust,
Kotlin and Swift. It would be very much easy if ranges are supported
4. Privacy and underscores should not be enforced.
- Most dynamic languages do not need privacy and Dart should avoid that
at least by specification and in examples. It should have clear guidelines
about where not to play with ugly underscores. it is ok to denote private
variables with underscore prefix but what about methods. they look ugly.
There should be some kind of annotation or something that generate this
instead of
void _doSomethingAmazing(){} can be used as
@LibPrivate
void doSomethingAmazing(){} to avoid underscores for methods who dislike
them.
5. Inconstancy in static type system
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

[Milan Zimmermann]

Yeah :) .. I just went for enforcement of an existing option, rather than a
change. But I realize this is almost certainly impossible due to existing
code (and maybe many would not like it even if enforced parameter names
existed from the beginning).

Post by Benjamin Strauß
If you go that far you could make one step further and switch to smalltalk
infix notation. ;)

Post by Milan Zimmermann
My largest plus would be for an item that is not on this list :)
"Make named parameters required" (do not allow unnamed, as a default or
otherwise).
I realize it may be too late in the life of a language for a change like
this. But, well I just feel, for multiple reasons, primary being that code
is read so much more often then written, languages should enforce it. I
had a whole list of +-0s for this thread but in the end, I realized my
favorite is not on the list :(

Post by Droid Experiments
First of all, please don't be offended on what I'm talking about. Dart
is the coolest programming language ever. Optional typing, great tools and
great built-in libraries are the coolest things that attracts me and keep
me writing Dart more and more. But when I write Dart; I feel many things
missing. As a modern programming language; there are couple of small things
proposed but never implemented. I want to talk them again.
1. First one is the variable declaration. syntax. There is a need for
better variable declaration syntax that enforce immutability.
five letter keywords like 'final' and 'const' are not good. Most people
won't use it even if most of the variables in their program can be treated
as final.
There should be three letter keyword for each.
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];
and also time inference should be fully supported by the specification
and not the implementation do that.
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)
3. Switch should be powerful.
- switch should break by default - I think most modern languages go this
way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust,
Kotlin and Swift. It would be very much easy if ranges are supported
4. Privacy and underscores should not be enforced.
- Most dynamic languages do not need privacy and Dart should avoid that
at least by specification and in examples. It should have clear guidelines
about where not to play with ugly underscores. it is ok to denote private
variables with underscore prefix but what about methods. they look ugly.
There should be some kind of annotation or something that generate this
instead of
void _doSomethingAmazing(){} can be used as
@LibPrivate
void doSomethingAmazing(){} to avoid underscores for methods who dislike
them.
5. Inconstancy in static type system
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

[Günter Zöchbauer]

You can use @required from https://pub.dartlang.org/packages/meta to get
analyzer support.

/// Used to annotate a named parameter `p` in a method or function `f`./// Indicates that every invocation of `f` must include an argument/// corresponding to `p`, despite the fact that `p` would otherwise be an/// optional parameter.////// Tools, such as the analyzer, can provide feedback if////// * the annotation is associated with anything other than a named parameter,/// * the annotation is associated with a named parameter in a method `m1` that/// overrides a method `m0` and `m0` defines a named parameter with the same/// name that does not have this annotation, or/// * an invocation of a method or function does not include an argument/// corresponding to a named parameter that has this annotation.const Required <https://www.crossdart.info/p/meta/1.0.1/meta.dart.html#line-103> required = const Required <https://www.crossdart.info/p/meta/1.0.1/meta.dart.html#line-103>();

Post by Milan Zimmermann
My largest plus would be for an item that is not on this list :)
"Make named parameters required" (do not allow unnamed, as a default or
otherwise).
I realize it may be too late in the life of a language for a change like
this. But, well I just feel, for multiple reasons, primary being that code
is read so much more often then written, languages should enforce it. I
had a whole list of +-0s for this thread but in the end, I realized my
favorite is not on the list :(

Post by Droid Experiments
First of all, please don't be offended on what I'm talking about. Dart is
the coolest programming language ever. Optional typing, great tools and
great built-in libraries are the coolest things that attracts me and keep
me writing Dart more and more. But when I write Dart; I feel many things
missing. As a modern programming language; there are couple of small things
proposed but never implemented. I want to talk them again.
1. First one is the variable declaration. syntax. There is a need for
better variable declaration syntax that enforce immutability.
five letter keywords like 'final' and 'const' are not good. Most people
won't use it even if most of the variables in their program can be treated
as final.
There should be three letter keyword for each.
- var : for mutable
- val : for shallow immutable i.e final Point x = new Point(0,0); should
be val x = new Point(0,0);
- def : for deep immutable i.e. const x = [1,2]; should be def x = [1,2];
and also time inference should be fully supported by the specification
and not the implementation do that.
- for(var i=0;i<10;i++) can be replaced by for(var i in 1...10) or
for(var i in 1 to 10)
- tuples should be supported. It should be possible to return multiple
values from a function in one or another way. (take the Kotlin for example
: it has nice data annotation to make small value classes to eliminate the
need for tuples)
3. Switch should be powerful.
- switch should break by default - I think most modern languages go this
way. Showing a error for break is nice but annoying.
- switch statement should support full pattern matching like Rust, Kotlin
and Swift. It would be very much easy if ranges are supported
4. Privacy and underscores should not be enforced.
- Most dynamic languages do not need privacy and Dart should avoid that
at least by specification and in examples. It should have clear guidelines
about where not to play with ugly underscores. it is ok to denote private
variables with underscore prefix but what about methods. they look ugly.
There should be some kind of annotation or something that generate this
instead of
void _doSomethingAmazing(){} can be used as
@LibPrivate
void doSomethingAmazing(){} to avoid underscores for methods who dislike
them.
5. Inconstancy in static type system
why there are int and num? to maintain a compatibility with JS or are
there any other reasons? Why String is written with first capital letter
but int is not? In Java, it has reasons for that. You should "draw a line"
and the line is to make each type follow Capsfirst.

['Bob Nystrom' via Dart Misc]

Post by Milan Zimmermann
"Make named parameters required" (do not allow unnamed, as a default or
otherwise).
I realize it may be too late in the life of a language for a change like
this.

Dart 2.0 does open the door to breaking changes, so it's not strictly off
the table.

We have talked about required named parameters. I personally would like
them, and our story around named and optional parameters needs some work
anyway. Almost no one likes the declaration syntax ("=" for positional
defaults, ":" for named defaults = WTF), and the fact that you can't have
both optional positional and named in one method causes real API evolution
problems.

Having said that, though, required named parameters aren't a real burning
issue as far as I can tell, so we may not do anything about them.

Cheers!

– bob

['Yegor Jbanov' via Dart Misc]

One approach for required named parameters that's being investigated right
now is `package:meta/meta.dart` and @required annotation. It is currently
implemented in the analyzer version used by Flutter. Try the following in a
Flutter app in Atom:

import 'package:meta/meta.dart';

void latte({@required int milk}) {}

void main() {
latte(); // analyzer warning
latte(milk: 10); // ok
}


On Wed, Jul 6, 2016 at 10:34 AM 'Bob Nystrom' via Dart Misc <

On Mon, Jul 4, 2016 at 5:15 PM, Milan Zimmermann <

Post by Milan Zimmermann
"Make named parameters required" (do not allow unnamed, as a default or
otherwise).
I realize it may be too late in the life of a language for a change like
this.

Dart 2.0 does open the door to breaking changes, so it's not strictly off
the table.
We have talked about required named parameters. I personally would like
them, and our story around named and optional parameters needs some work
anyway. Almost no one likes the declaration syntax ("=" for positional
defaults, ":" for named defaults = WTF), and the fact that you can't have
both optional positional and named in one method causes real API evolution
problems.
Having said that, though, required named parameters aren't a real burning
issue as far as I can tell, so we may not do anything about them.
Cheers!
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to a topic in the
Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/dartlang.org/d/topic/misc/QJMDae-3iXc/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to

[Jan Mostert]

@Bob, I quite like how Kotlin does named parameters and default values, it
feels a lot more natural - you can also treat positional arguments as named
parameters in the event that a function requires a lot of positional
parameters which makes code a lot more readable.

Post by 'Yegor Jbanov' via Dart Misc
One approach for required named parameters that's being investigated right
implemented in the analyzer version used by Flutter. Try the following in a
import 'package:meta/meta.dart';
void main() {
latte(); // analyzer warning
latte(milk: 10); // ok
}
On Wed, Jul 6, 2016 at 10:34 AM 'Bob Nystrom' via Dart Misc <

On Mon, Jul 4, 2016 at 5:15 PM, Milan Zimmermann <

Post by Milan Zimmermann
"Make named parameters required" (do not allow unnamed, as a default or
otherwise).
I realize it may be too late in the life of a language for a change like
this.

Dart 2.0 does open the door to breaking changes, so it's not strictly off
the table.
We have talked about required named parameters. I personally would like
them, and our story around named and optional parameters needs some work
anyway. Almost no one likes the declaration syntax ("=" for positional
defaults, ":" for named defaults = WTF), and the fact that you can't have
both optional positional and named in one method causes real API evolution
problems.
Having said that, though, required named parameters aren't a real burning
issue as far as I can tell, so we may not do anything about them.
Cheers!
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---

You received this message because you are subscribed to a topic in the

Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/dartlang.org/d/topic/misc/QJMDae-3iXc/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Michael Francis]

I think I've seen mention that they may change type declarations to be more
like other "civilized" languages. Like:
var name: String = "Bob";

this could help with method declarations

void myMethod(requiredLastName:string, optionalFirstName:string = "Bob", {
ageRequired: number, heightOptional:number = 100 })

Post by Jan Mostert
@Bob, I quite like how Kotlin does named parameters and default values, it
feels a lot more natural - you can also treat positional arguments as named
parameters in the event that a function requires a lot of positional
parameters which makes code a lot more readable.

Post by 'Yegor Jbanov' via Dart Misc
One approach for required named parameters that's being investigated
currently implemented in the analyzer version used by Flutter. Try the
import 'package:meta/meta.dart';
void main() {
latte(); // analyzer warning
latte(milk: 10); // ok
}
On Wed, Jul 6, 2016 at 10:34 AM 'Bob Nystrom' via Dart Misc <

On Mon, Jul 4, 2016 at 5:15 PM, Milan Zimmermann <

Post by Milan Zimmermann
"Make named parameters required" (do not allow unnamed, as a default or
otherwise).
I realize it may be too late in the life of a language for a change
like this.

Dart 2.0 does open the door to breaking changes, so it's not strictly
off the table.
We have talked about required named parameters. I personally would like
them, and our story around named and optional parameters needs some work
anyway. Almost no one likes the declaration syntax ("=" for positional
defaults, ":" for named defaults = WTF), and the fact that you can't have
both optional positional and named in one method causes real API evolution
problems.
Having said that, though, required named parameters aren't a real
burning issue as far as I can tell, so we may not do anything about them.
Cheers!
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---

You received this message because you are subscribed to a topic in the

Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/dartlang.org/d/topic/misc/QJMDae-3iXc/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[tekz omnisoft]

Just curious! It's probably just personal preference, but why is this
considered better?
var name: String = "Bob";

It seems more verbose to me than
String name = "Bob";

Post by Michael Francis
I think I've seen mention that they may change type declarations to be
var name: String = "Bob";
this could help with method declarations
void myMethod(requiredLastName:string, optionalFirstName:string = "Bob", {
ageRequired: number, heightOptional:number = 100 })

Post by Jan Mostert
@Bob, I quite like how Kotlin does named parameters and default values,
it feels a lot more natural - you can also treat positional arguments as
named parameters in the event that a function requires a lot of positional
parameters which makes code a lot more readable.
On Wed, 06 Jul 2016, 19:44 'Yegor Jbanov' via Dart Misc <

Post by 'Yegor Jbanov' via Dart Misc
One approach for required named parameters that's being investigated
currently implemented in the analyzer version used by Flutter. Try the
import 'package:meta/meta.dart';
void main() {
latte(); // analyzer warning
latte(milk: 10); // ok
}
On Wed, Jul 6, 2016 at 10:34 AM 'Bob Nystrom' via Dart Misc <

On Mon, Jul 4, 2016 at 5:15 PM, Milan Zimmermann <

Post by Milan Zimmermann
"Make named parameters required" (do not allow unnamed, as a default
or otherwise).
I realize it may be too late in the life of a language for a change
like this.

Dart 2.0 does open the door to breaking changes, so it's not strictly
off the table.
We have talked about required named parameters. I personally would like
them, and our story around named and optional parameters needs some work
anyway. Almost no one likes the declaration syntax ("=" for positional
defaults, ":" for named defaults = WTF), and the fact that you can't have
both optional positional and named in one method causes real API evolution
problems.
Having said that, though, required named parameters aren't a real
burning issue as far as I can tell, so we may not do anything about them.
Cheers!
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---

You received this message because you are subscribed to a topic in the

Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/dartlang.org/d/topic/misc/QJMDae-3iXc/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

['Bob Nystrom' via Dart Misc]

Post by tekz omnisoft
Just curious! It's probably just personal preference, but why is this
considered better?
var name: String = "Bob";
It seems more verbose to me than
String name = "Bob";

It is more verbose when annotating a local variable, yes. But in most
languages that use this syntax, local variables are rarely annotated. For
things like parameters, it's not much more verbose (just the ":" character).

There are a bunch of pros and cons around this, but the main one is that it
makes the grammar a little cleaner and easier to evolve. Imagine you're the
parser and you're sitting at the beginning of a statement, like here:


main() {
<parser is here...>
}


Among other things, a statement can be an expression statement or a local
variable declaration. The former is any expression followed by a ";". The
latter is a type annotation (or "var", etc.) followed by a name and
optional initializer.

That means that when the parser is parsing the beginning of a statement, it
doesn't know whether it's looking at an expression or a type annotation.
Consider, for example a line that starts with:

A < B < C < D < E


Is that an expression statement containing a series of chained "<"
operators? (It's not a *useful* one, of course, but it could be
grammatically correct.) Or is it a local variable declaration of some
deeply nested generic type?

The ambiguity doesn't get resolved until you reach either a semicolon or a
variable name and can tell what you got. In the meantime, the parser's life
is harder because it has to deal with the fact that it could be either.

In this specific case, the language designers dodged the issue by tweaking
the grammar around comparison operators to disallow chaining them. But
that's not a general solution. Consider other kinds of type annotations we
may want to support later:

A | B | C | D


Is this a series of chained | operators, or a local variable whose type is
a union type?

Keeping types on the left isn't intractable, but it does make things more
annoying for tools since it means the type annotation and expression
grammars sort of sit on top of each other. Putting types after ":" keeps it
simpler and clearer.

Cheers!

– bob

[Michael Francis]

There's one syntax change I'd like to vote for: Change multi line strings
from triple quotes to a grave accent.

A lot of IDEs out there have poor support for the triple quotes. Plus it's
a lot of key strokes.

On Wed, Jul 6, 2016 at 4:25 PM 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by tekz omnisoft
Just curious! It's probably just personal preference, but why is this
considered better?
var name: String = "Bob";
It seems more verbose to me than
String name = "Bob";

It is more verbose when annotating a local variable, yes. But in most
languages that use this syntax, local variables are rarely annotated. For
things like parameters, it's not much more verbose (just the ":" character).
There are a bunch of pros and cons around this, but the main one is that
it makes the grammar a little cleaner and easier to evolve. Imagine you're
main() {
<parser is here...>
}
Among other things, a statement can be an expression statement or a local
variable declaration. The former is any expression followed by a ";". The
latter is a type annotation (or "var", etc.) followed by a name and
optional initializer.
That means that when the parser is parsing the beginning of a statement,
it doesn't know whether it's looking at an expression or a type annotation.
A < B < C < D < E
Is that an expression statement containing a series of chained "<"
operators? (It's not a *useful* one, of course, but it could be
grammatically correct.) Or is it a local variable declaration of some
deeply nested generic type?
The ambiguity doesn't get resolved until you reach either a semicolon or a
variable name and can tell what you got. In the meantime, the parser's life
is harder because it has to deal with the fact that it could be either.
In this specific case, the language designers dodged the issue by tweaking
the grammar around comparison operators to disallow chaining them. But
that's not a general solution. Consider other kinds of type annotations we
A | B | C | D
Is this a series of chained | operators, or a local variable whose type is
a union type?
Keeping types on the left isn't intractable, but it does make things more
annoying for tools since it means the type annotation and expression
grammars sort of sit on top of each other. Putting types after ":" keeps it
simpler and clearer.
Cheers!
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

['Lasse R.H. Nielsen' via Dart Misc]

Post by Michael Francis
There's one syntax change I'd like to vote for: Change multi line strings
from triple quotes to a grave accent.
A lot of IDEs out there have poor support for the triple quotes. Plus it's
a lot of key strokes.

One advantage that triple quotes has over single quotes of any kind is that
it's unlikely that to occur in the string. I use triple-quoted strings on a
single line when the string needs to contain both ' and ".
Try writing your dartdoc in a string!
const doc = """If the `foo` isn't `"bar"`, don't do it!""";

/L
--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[JB]

One of the pain points for my use is typedefs, they just feel bad. I don't
think there is way to describe a class holding a reference to a function
without them, since it would be ambiguous with method syntax. Maybe
overall it's not the biggest issue, but I think it contributes to the
language feeling a lot less dynamic or flexible than it can be.

[Nick Reid]

+1 to this. It sounds unnatural to me, like French where adjectives sometimes come after their associated noun. Also the verbosity, if 5 letter keywords are a pain point for getting immutable values into use, this syntax just makes me not want to specify types at all. I get it might make the (automated) parsers life harder, but the onus should be on the computer to make things easier for humans, not to dictate terms.

Just curious! It's probably just personal preference, but why is this considered better?
var name: String = "Bob";
It seems more verbose to me than
String name = "Bob";

Post by Michael Francis
var name: String = "Bob";
this could help with method declarations
void myMethod(requiredLastName:string, optionalFirstName:string = "Bob", { ageRequired: number, heightOptional:number = 100 })

@Bob, I quite like how Kotlin does named parameters and default values, it feels a lot more natural - you can also treat positional arguments as named parameters in the event that a function requires a lot of positional parameters which makes code a lot more readable.

Post by 'Yegor Jbanov' via Dart Misc
import 'package:meta/meta.dart';
void main() {
latte(); // analyzer warning
latte(milk: 10); // ok
}

"Make named parameters required" (do not allow unnamed, as a default or otherwise).
I realize it may be too late in the life of a language for a change like this.

Dart 2.0 does open the door to breaking changes, so it's not strictly off the table.
We have talked about required named parameters. I personally would like them, and our story around named and optional parameters needs some work anyway. Almost no one likes the declaration syntax ("=" for positional defaults, ":" for named defaults = WTF), and the fact that you can't have both optional positional and named in one method causes real API evolution problems.
Having said that, though, required named parameters aren't a real burning issue as far as I can tell, so we may not do anything about them.
Cheers!
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to a topic in the Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit https://groups.google.com/a/dartlang.org/d/topic/misc/QJMDae-3iXc/unsubscribe.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.

['Lasse R.H. Nielsen' via Dart Misc]

Post by Nick Reid
+1 to this. It sounds unnatural to me, like French where adjectives
sometimes come after their associated noun. Also the verbosity, if 5
letter keywords are a pain point for getting immutable values into use,
this syntax just makes me not want to specify types at all.

We shouldn't underestimate the cost of having to press shift to insert a
':'.

The Go language has types-last but has no colon, and a shorthand to avoid
writing both "var" and the type. If we want this, I think that's where we
should be looking.

Post by Nick Reid
I get it might make the (automated) parsers life harder, but the onus
should be on the computer to make things easier for humans, not to dictate
terms.

The problem isn't there if it just makes parsing hard. It's only if it
makes parsing impossible, because the grammar becomes ambiguous, that we
have a problem.

/L

Post by Nick Reid
Just curious! It's probably just personal preference, but why is this considered better?
var name: String = "Bob";
It seems more verbose to me than
String name = "Bob";

Post by Michael Francis
I think I've seen mention that they may change type declarations to be
var name: String = "Bob";
this could help with method declarations
void myMethod(requiredLastName:string, optionalFirstName:string = "Bob",
{ ageRequired: number, heightOptional:number = 100 })

Post by Jan Mostert
@Bob, I quite like how Kotlin does named parameters and default values,
it feels a lot more natural - you can also treat positional arguments as
named parameters in the event that a function requires a lot of positional
parameters which makes code a lot more readable.
On Wed, 06 Jul 2016, 19:44 'Yegor Jbanov' via Dart Misc <

Post by 'Yegor Jbanov' via Dart Misc
One approach for required named parameters that's being investigated
currently implemented in the analyzer version used by Flutter. Try the
import 'package:meta/meta.dart';
void main() {
latte(); // analyzer warning
latte(milk: 10); // ok
}
On Wed, Jul 6, 2016 at 10:34 AM 'Bob Nystrom' via Dart Misc <

On Mon, Jul 4, 2016 at 5:15 PM, Milan Zimmermann <

Post by Milan Zimmermann
"Make named parameters required" (do not allow unnamed, as a default
or otherwise).
I realize it may be too late in the life of a language for a change like this.

Dart 2.0 does open the door to breaking changes, so it's not strictly
off the table.
We have talked about required named parameters. I personally would
like them, and our story around named and optional parameters needs some
work anyway. Almost no one likes the declaration syntax ("=" for positional
defaults, ":" for named defaults = WTF), and the fact that you can't have
both optional positional and named in one method causes real API evolution
problems.
Having said that, though, required named parameters aren't a real
burning issue as far as I can tell, so we may not do anything about them.
Cheers!
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---

You received this message because you are subscribed to a topic in the

Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/dartlang.org/d/topic/misc/QJMDae-3iXc/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[tatumizer-v0.2]

I spent some time programming in Kotlin. Very well-thought-out language,
with some original features (like extension lambdas), has everything you
need for happiness.
That is, in theory. However, in practice, this right-side typing just made
me mad. This shift-colon thing... and space after colon... and then, it's
difficult to read because of too much punctuation.

The price for right-hand typing is disproportionately big. It's not an
isolated feature, like writing "var foo:String" instead of "String foo".
No, it has other consequences. E.g., how to write the type of return value
for function? Like this: "fun foo(x:String):String" ?

Then there's a problem to declare functional parameter. E.g, "fun
bar(x:(String):String)" doesn't look good (2 colons). So in such cases,
Kotlin defines different syntax:

"fun bar(x:(String) -> String)". (arrow instead of colon). Hm... The
alternative could be to require -> in every context, including definition,
e.g "fun foo(x:String) -> String".

Which is exactly what swift does: for variables, it's colon; for functions
- arrow, just *always* instead of *sometimes*. Still ugly. Too much fancy
punctuation, to what end?

For grammar to be unambiguous and easy to parse, it's enough to introduce
one extra rule: types start with upper-case letter, variables - with
lowercase. That's it.
You can still write types on the left, no colons or arrows, easy to write,
easy to read...
What's wrong with that? This rule is followed by everybody anyway,
otherwise program won't pass code review... I think we already discussed
that, but I don't remember the arguments against it.

[Nick Reid]

Obviously the grammar still has to be unambiguous, but mangling a very common case (variable declaration) seems like the wrong way to go about it. If we _really_ have to add symbols for disambiguation they should go in the more esoteric cases.

Post by Nick Reid
+1 to this. It sounds unnatural to me, like French where adjectives sometimes come after their associated noun. Also the verbosity, if 5 letter keywords are a pain point for getting immutable values into use, this syntax just makes me not want to specify types at all.

We shouldn't underestimate the cost of having to press shift to insert a ':'.
The Go language has types-last but has no colon, and a shorthand to avoid writing both "var" and the type. If we want this, I think that's where we should be looking.

Post by Nick Reid
I get it might make the (automated) parsers life harder, but the onus should be on the computer to make things easier for humans, not to dictate terms.

The problem isn't there if it just makes parsing hard. It's only if it makes parsing impossible, because the grammar becomes ambiguous, that we have a problem.
/L

Post by Nick Reid

Just curious! It's probably just personal preference, but why is this considered better?
var name: String = "Bob";
It seems more verbose to me than
String name = "Bob";

Post by Michael Francis
var name: String = "Bob";
this could help with method declarations
void myMethod(requiredLastName:string, optionalFirstName:string = "Bob", { ageRequired: number, heightOptional:number = 100 })

@Bob, I quite like how Kotlin does named parameters and default values, it feels a lot more natural - you can also treat positional arguments as named parameters in the event that a function requires a lot of positional parameters which makes code a lot more readable.

Post by 'Yegor Jbanov' via Dart Misc
import 'package:meta/meta.dart';
void main() {
latte(); // analyzer warning
latte(milk: 10); // ok
}

"Make named parameters required" (do not allow unnamed, as a default or otherwise).
I realize it may be too late in the life of a language for a change like this.

Dart 2.0 does open the door to breaking changes, so it's not strictly off the table.
We have talked about required named parameters. I personally would like them, and our story around named and optional parameters needs some work anyway. Almost no one likes the declaration syntax ("=" for positional defaults, ":" for named defaults = WTF), and the fact that you can't have both optional positional and named in one method causes real API evolution problems.
Having said that, though, required named parameters aren't a real burning issue as far as I can tell, so we may not do anything about them.
Cheers!
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to a topic in the Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit https://groups.google.com/a/dartlang.org/d/topic/misc/QJMDae-3iXc/unsubscribe.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.

--
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K - Denmark - CVR nr. 28 86 69 84
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.

[Jan Mostert]

Speaking about Kotlin, the "with" keyword is very nice, I know it does the
same as double-dot, but when you have to use it in a nested way, it's much
more readable than double-dot

with (a) {
val1 = 1
val2 = 2
with (val3) (
vala = 1
valb = 2
print(this) <<-- will print a.val3
}

whereas Dart:

a..val1 = 1
..val2 = 2
..val3..vala = 1
..valb = 2
and then if I want to assign values to val3 (vala and valb), it gets a
bit ambiguous (the above is probably invalid since the double-dot will mean
a.vala and a.valb instead of a.val3.vala and a.val3.valb

For the times when mapping levels of nested fields without some sort of
reflection, the with keyword is awesome.

Post by Nick Reid
Obviously the grammar still has to be unambiguous, but mangling a very
common case (variable declaration) seems like the wrong way to go about
it. If we _really_ have to add symbols for disambiguation they should go
in the more esoteric cases.
On Jul 9, 2016, at 7:43 AM, 'Lasse R.H. Nielsen' via Dart Misc <

Post by Nick Reid
+1 to this. It sounds unnatural to me, like French where adjectives
sometimes come after their associated noun. Also the verbosity, if 5
letter keywords are a pain point for getting immutable values into use,
this syntax just makes me not want to specify types at all.

We shouldn't underestimate the cost of having to press shift to insert a ':'.
The Go language has types-last but has no colon, and a shorthand to avoid
writing both "var" and the type. If we want this, I think that's where we
should be looking.

Post by Nick Reid
I get it might make the (automated) parsers life harder, but the onus
should be on the computer to make things easier for humans, not to dictate
terms.

The problem isn't there if it just makes parsing hard. It's only if it
makes parsing impossible, because the grammar becomes ambiguous, that we
have a problem.
/L

Post by Nick Reid
Just curious! It's probably just personal preference, but why is this considered better?
var name: String = "Bob";
It seems more verbose to me than
String name = "Bob";

Post by Michael Francis
I think I've seen mention that they may change type declarations to be
var name: String = "Bob";
this could help with method declarations
void myMethod(requiredLastName:string, optionalFirstName:string = "Bob",
{ ageRequired: number, heightOptional:number = 100 })

Post by Jan Mostert
@Bob, I quite like how Kotlin does named parameters and default values,
it feels a lot more natural - you can also treat positional arguments as
named parameters in the event that a function requires a lot of positional
parameters which makes code a lot more readable.
On Wed, 06 Jul 2016, 19:44 'Yegor Jbanov' via Dart Misc <

Post by 'Yegor Jbanov' via Dart Misc
One approach for required named parameters that's being investigated
currently implemented in the analyzer version used by Flutter. Try the
import 'package:meta/meta.dart';
void main() {
latte(); // analyzer warning
latte(milk: 10); // ok
}
On Wed, Jul 6, 2016 at 10:34 AM 'Bob Nystrom' via Dart Misc <

On Mon, Jul 4, 2016 at 5:15 PM, Milan Zimmermann <

Post by Milan Zimmermann
"Make named parameters required" (do not allow unnamed, as a default
or otherwise).
I realize it may be too late in the life of a language for a change like this.

Dart 2.0 does open the door to breaking changes, so it's not strictly
off the table.
We have talked about required named parameters. I personally would
like them, and our story around named and optional parameters needs some
work anyway. Almost no one likes the declaration syntax ("=" for positional
defaults, ":" for named defaults = WTF), and the fact that you can't have
both optional positional and named in one method causes real API evolution
problems.
Having said that, though, required named parameters aren't a real
burning issue as far as I can tell, so we may not do anything about them.
Cheers!
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---

You received this message because you are subscribed to a topic in the

Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/dartlang.org/d/topic/misc/QJMDae-3iXc/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[tatumizer-v0.2]

"with" is not a keyword. It's a normal function from standard library,
defined using extension lambda:
fun <T, R> with(receiver: T, block: *T.()* -> R): R,
see https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/with.html

[Milan Zimmermann]

Right, thanks. And agree on the positional vs named defaults fwiw.

Post by 'Bob Nystrom' via Dart Misc

Post by Milan Zimmermann
"Make named parameters required" (do not allow unnamed, as a default or
otherwise).
I realize it may be too late in the life of a language for a change like
this.

Dart 2.0 does open the door to breaking changes, so it's not strictly off
the table.
We have talked about required named parameters. I personally would like
them, and our story around named and optional parameters needs some work
anyway. Almost no one likes the declaration syntax ("=" for positional
defaults, ":" for named defaults = WTF), and the fact that you can't have
both optional positional and named in one method causes real API evolution
problems.
Having said that, though, required named parameters aren't a real burning
issue as far as I can tell, so we may not do anything about them.
Cheers!
– bob