9/2 language meeting notes

[Bob Nystrom]

Here's my notes from this week's now hour long meeting:

https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md

I mention this in the notes, but I want to call it out here. We're starting to discuss this vague notion of "Dart 2.0". We don't know what that means yet, and that means we'll be talking about all kinds of crazy radical ideas which may or may not come to pass.

I think it's really important for us to speak freely, and it's also important to do this in the open so we can involve all of you. But the cost is that you may hear ideas that seem scary or disruptive, or ideas that sound awesome but don't pan out. Try not to freak out and understand that we're just brainstorming at this point.

Cheers!

- bob

[Patrice Chalin]

+1 on all counts!

--
You received this message because you are subscribed to the Google Groups "Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to core-dev+u...@dartlang.org.

--

Patrice   

[Brian Slesinsky]

re: reified types, I'm no longer using them in the PbList class in the protobuf library [1]. The problem was that when constructing a list, it's difficult to pass in the list item type as a parameter to an overridable method that calls the list constructor. So, the new plan is to pass in a "check" function instead of a runtime type. A function is more flexible anyway, since some checks aren't Dart type checks. (For example, some PbLists only accept 32-bit integers.)

The main thing on my wishlist is some kind of "implemented by" clause on a Dart class. For example, you should be able to do this:

abstract class HasIdAndName implemented by SomeProto, Proto2, Proto3 {

  String get id;

  String get name;

}

This would make it easy for teams to do their own thing instead of having to file a feature request to get a new interface added to a lower-level library, which results in unfortunate and unnecessary political discussions and perhaps even changes to build tools (in the case of protobufs) to allow adding new library dependencies in unlikely places.

It would also let you create your own union types, so some folks might like that too.

[1] https://github.com/dart-lang/dart-protobuf/commit/5e603aeebe39c85f3f077d5eec8e0c35f9265e0b

--
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

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Günter Zöchbauer]

+1 Static checking for dropped futures

"_" should not cause unused variable hints anywhere (not only in arguments)

Doesn't work for inline calls though `print(asyncCall())`

Reified generics

I don't know the consequences but since Patrice explained to me that `<TypeA,TypeB>{}` is not the same than `new Map<TypeA,TypeB>()` I don't like reified generics much.

Type tests

while Objectautomatically gets one that returns false

I would expect object always to return `true` not `false` 

Type annotations on the right

I'm not used to this style (never really developed in a language with this style)

I feels quite cumbersome. Especially that `var` is necessary in addition to the type everywhere.

Something like

var {
  a : int;
  b : String;
}

would easy this pain a lot.

This might even be a solution for (or instead of) final by default

var {
  a: int;
  b: String;
}
 
final {
  c: num;
  d: bol;
}

This is meant in addition to 

var a: int;

not instead of.

+10 Constructor initialization lists

for moving `super` into the constructor block and treat the statements before `super` like the initializer list but more powerful.

Parts

In my main project I use parts a lot but I could live without it.

I want to ensure private members are accessible within the code in the whole library but the library is way to big for one file.

I don't care much about preventing developers accessing my private members but the classes are quite complex and I don't want all of the internal members to clutter the autocompletion list of developers.

Some scope name, where the members are listed when the caller is in the same scope, would do it for me. The scope could be the library name if it is allowed to load more than one file with the same library name or maybe some declaration in addition to `library`;

I also would like a way to indicate that a member is "protected" (public but should only be referenced from subclasses). Here also I mostly care about the autocompletion list. A hint from the analyzer would be nice as well for violations though.

+5 Fields final by default

See also my comment above about "Type annotations on the right"

I'm in favor for "final by default" but not only for fields 

but especially for function/method parameters 

and also for local variables.

Remove break, continue, and labels in favor of non-local returns

I don't need break, continue a lot and an if usually is enough for a workaround but ugly.

Would be nice to hear more about the consequences (advantages/disadvantages/alternative approaches).

AFAIK this is required for tail recursion which would allow Dart to perform better in functional style programming.

Assert

One advantage of assert is that it has no runtime cost in production code.

I see this more like an inline unit test and "active" documentation of intent.

I'm +5 for contracts or similar expressive ways but this might cost to much performance for production.

But some checks should be active in production for input validation.

+5 for expressive checks/validation

+3 for still being able to define which checks should be executed only in checked mode.

Uniformity of reference

I guess this would be harder to swallow than type annotations on the right.

How to differentiate between calling a function referenced by a field and getting the reference to the function?

+1 Removing new

I don't care too much, but I find it often cumbersome to differentiate between static methods returning an instance and (factory) constructors.

If `const` goes away `new` definitely has to go as well.

[Lasse R.H. Nielsen]

On Fri, Sep 4, 2015 at 10:09 AM, Günter Zöchbauer <gzo...@gmail.com> wrote:

Reified generics

I don't know the consequences but since Patrice explained to me that `<TypeA,TypeB>{}` is not the same than `new Map<TypeA,TypeB>()` I don't like reified generics much.

I would like to see that explanation - it should be exactly the same.

 

Type tests

while Objectautomatically gets one that returns false

I would expect object always to return `true` not `false` 

If the "is" method is on the object and takes the type as argument, then

the default method should use the type of the current object and see if it implements the type represented by the argument. It should neither return always true or always false.

I'd do: 

  bool operator is(Type type)

with a default that does exactly what "obj is TypeName" does now. The only difference is that you can override it. The disadvantage is that now type checks can have side-effects, including throwing.

 

Type annotations on the right

I'm not used to this style (never really developed in a language with this style)

I feels quite cumbersome. Especially that `var` is necessary in addition to the type everywhere.

Something like

var {
  a : int;
  b : String;
}

would easy this pain a lot.

var a: int = 42, b: String = "foo";

That seems like a direct extension of current syntax that I'd expect to just work.

 

This might even be a solution for (or instead of) final by default

var {
  a: int;
  b: String;
}
 
final {
  c: num;
  d: bol;
}

This is meant in addition to 

var a: int;

not instead of.

 

+10 Constructor initialization lists

for moving `super` into the constructor block and treat the statements before `super` like the initializer list but more powerful.

But whyyy?!?

Having something that looks like normal code inside the body of the constructor, but with some non-obvious restrictions, and then a super call that looks like a super method call (in case of a named constructor), it's going to be practically invisible that something different is going on.

I think initializer lists are great, and very, very readable.

 

Uniformity of reference

I guess this would be harder to swallow than type annotations on the right.

How to differentiate between calling a function referenced by a field and getting the reference to the function?

Good point. If the "()" is optional, then you can call a nullary function both as a getter "x.foo" and as a function "x.foo()". That means you have two ways to write the same thing, which is not great. It makes "x.foo()" ambiguous - is it calling a nullary function with no arguments and then calling the result, or is it just calling a nullary function. 

It'll likely be disambiguated to mean calling the method with no arguments, and then you have to write (x.foo)() to call the result of a getter.

Also, should you be allowed to pass zero arguments to a getter?

 

+1 Removing new

I don't care too much, but I find it often cumbersome to differentiate between static methods returning an instance and (factory) constructors.

If `const` goes away `new` definitely has to go as well.

+5.

It's still not perfect - a generative constructor is different from any other member because it's necessary for extending a class.

Maybe we should drop "extends" from the language, and replace it with auto-delegation.

Instead of "class C extends D { something(); }" you do:

   class C implements D as _d {

     final D _d;

     something();

   }

which automatically adds delegates for all members on D to call the same method on _d.

Then you don't need to have publicly visible generative constructors at all.

/L

--

Lasse R.H. Nielsen - l...@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

[Rasmus Eneman]

There are a lot of changes mentioned, and while I think an open discussion is great I'm scared for the scenario of Python 3 in Dart.

Dart have a much smaller community and splitting it could nearly kill it.

Reified generics

I can't see the reason for removal of reified generics. I expect that is has to do with performance, and have to ask, is the difference significant?

Can't that optimization be done at run-time when the VM figures out that the type information wont be used?

The reason I ask is because reified generics do have use cases and type erasure doesn't provide any other. I have always seen Dart as a fast

language that still preserve the cool-features like optional-typing, reified generics. Removing reified generics would express that performance now

is more important than a great language, which would be sad I think.

Type tests

I like the is operator, but I can certainly see the use case mentioned. What if is would be an overridable operator like == and similar?

Type annotations on the right

Sounds to me mostly as a change for the sake of not looking to Java-like. Couldn't the function type be expressed like such?

class Observable {
  void() observer;
}

Static methods

Wohoo! One step closer to the mantra "everything is an object".

Parts

If the proposal to remove the library name is accepted I very much would like this to. Simplifying the language and the change can easily be done with a tool (maybe except for private stuff, but the tool could probably make them public and just not export them in the wrapper library)

Fields final by default

Yes please! To make it explicit what are mutable and will be changed should make the code easier to read.

Uniformity of reference

With generalized tear offs we don't need the without parentheses syntax to tear off the method so this should make it easier to change between a getter and a methods. How will it work with classes implementing function though? Will they be called and the tear of syntax be needed to get hold of the object?

--
You received this message because you are subscribed to the Google Groups "Dart Core Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to core-dev+u...@dartlang.org.

--

Rasmus Eneman

[Günter Zöchbauer]

On Friday, September 4, 2015 at 10:35:43 AM UTC+2, Lasse Reichstein Holst Nielsen wrote:

On Fri, Sep 4, 2015 at 10:09 AM, Günter Zöchbauer <gzo...@gmail.com> wrote:

Reified generics

I don't know the consequences but since Patrice explained to me that `<TypeA,TypeB>{}` is not the same than `new Map<TypeA,TypeB>()` I don't like reified generics much.

I would like to see that explanation - it should be exactly the same.

 

It's quite some time back, I guess it was a discussion on some Angular issue. 

AFAIR he mentioned `<TypeA,TypeB>{}` doesn't doesn't reify generic arguments. If you say it's the same I believe you of course ;-) and will have a better rest at night from now on.

 

 

Type tests

while Objectautomatically gets one that returns false

I would expect object always to return `true` not `false` 

If the "is" method is on the object and takes the type as argument, then

the default method should use the type of the current object and see if it implements the type represented by the argument. It should neither return always true or always false.

I see, didn't think it through properly. Thanks for clarification.

The `super` would be distinguishing enough for me. I'd prefer to have initialization code within a normal code block. I don't find initializer list readable at all. To me it's a weird form to organize code which is used nowhere else, and being able to use control structures like in normal code would be nice.

I'm not super happy with the non-obvious restrictions above `super`. I was thinking about another block instead like 

class SomeClass {
  SomeClass() {
    // initalize finals here;
  }
  super() {
    // further initialization
  }
}

a while back, but wasn't super happy with this either. 

Another idea:

class SomeClass {
  SomeClass() {

    final {
    // initalize finals here;
    } 
    super();
    // further initialization
  }
}

I just use `final` here because this is what I usually use initializer lists for and I guess some keyword would be necessary to make its intent clear.

I changed the scale of +x before I sent the mail and forgot to update it for this point.

Should be +2 instead of +10 to fit with the others. Seems I'm not yet fully awake.

 

 

Uniformity of reference

I guess this would be harder to swallow than type annotations on the right.

How to differentiate between calling a function referenced by a field and getting the reference to the function?

Good point. If the "()" is optional, then you can call a nullary function both as a getter "x.foo" and as a function "x.foo()". That means you have two ways to write the same thing, which is not great. It makes "x.foo()" ambiguous - is it calling a nullary function with no arguments and then calling the result, or is it just calling a nullary function. 

It'll likely be disambiguated to mean calling the method with no arguments, and then you have to write (x.foo)() to call the result of a getter.

I guess "x.foo()" would be fine. It is not really possible to disguise a field referencing a function as a function anyway (for example for a user of an API from within it's IDE).

I use this for example for default Grinder tasks where I can configure the default behavior by passing different functions to fields (the tasks-functions are acquired by Grinder using mirrors which limits the options a bit).

But the functions are only called by my internal implementation anyway which knows they are fields holding functions.

I really like the distinction between `xxx()` do something (even expensive, and eventually return some result) and `xxx` give me the value you're holding (even when behind the scenes it might do a bit more than just that).

I think without `()` it would be much harder to interpret code.

Also, should you be allowed to pass zero arguments to a getter?

 

+1 Removing new

I don't care too much, but I find it often cumbersome to differentiate between static methods returning an instance and (factory) constructors.

If `const` goes away `new` definitely has to go as well.

+5.

It's still not perfect - a generative constructor is different from any other member because it's necessary for extending a class.

Maybe we should drop "extends" from the language, and replace it with auto-delegation.

Instead of "class C extends D { something(); }" you do:

   class C implements D as _d {

     final D _d;

     something();

   }

which automatically adds delegates for all members on D to call the same method on _d.

Then you don't need to have publicly visible generative constructors at all.

Doesn't look too bad, but my imagination doesn't reach far enough to see how this would work out in different scenarios. You seem to be really adventurous :)

[Günter Zöchbauer]

On Friday, September 4, 2015 at 11:07:10 AM UTC+2, Robert Åkerblom-Andersson wrote:

Type annotations on the right

I think that if Dart 2.0 would go in that direction, would the ":" really be needed? I know Go is a different language in many ways but it works for them...

Yes, I do understand that it's easier to parse of course, but I feel that it could be parsed without the ":" as well... I can see that the "function as a variable" example might benefit from the ":" for better readability, but for variables (that are way more common), I find it somewhat in the way. It looks almost cumbersome to add types because of the extra typing, I might grow to like it, I don't know, but I don't really like looking at it right now..

I would not go as far as to say that I "HATE HATE HATE this" hehe, but I agree that it does look almost plain weird for normal vars and I think it would be off putting to a lot of devs... Some of you core language people might not really see this as you guys have seen so many different syntaxes, it's not that different if you have seen it before yourself, but lots of devs have never ever seen this type of syntax, where as I feel "just moving the type to the right" is a lot less unfamiliar. Sure any dev could get used to it, but Dart right now wants to add lots of new users not just adapt the existing ones...

 

While I have don't have a strong opinion for any way on this topic, from many comments I saw, types on the left are hated by a lot of people not coming from C-style languages. Can't say which side has more haters of the "other side" though.

 

As alternatives, while still keeping type annotations on the right (I think that alone is okay) I can think of three different ways to do it:

1. Simply remove the ":"

2. Make the ":" optional, then it can be added where needed for readability (like the function case) but not for simple String and int vars

3. Make the ":" required only for function variables, I know adding special cases might not be the "right way" in some sense, but it could maybe be a compromise worth doing in this case 

Something that was not mentioned in this meeting but that I read about earlier, was the idea of maybe making ";" optional. I think it was Bob that said basically that removing them completely might be a too big breaking change, but making them optional could be done since existing code would not break. 

I feel that there are a lot of similarities between the existing use of ";" and the proposed used of ":". It feels like both are added mostly to make parsing easier, while the truth is that the code could still be parsed quite good without them. I might be wrong, but it almost feel like a premature optimization considering how fast computers are today (no offense intended, I do way too much premature optimization myself as well). 

I think the idea of making both ";" and ":" optional could be worth considering as it would be simple to explain and understand... You can add them if you want for readability where needed or simply not use them at all. I understand the drawback of making something optional, it's not as "clean", but in this case I feel the compromise might be worth more to existing and new Dart developers.

Removing new

Yes, I was previously against this but after thinking some more and looking at examples I have switched over to the "yes camp". I now feel it would be a nice change if it was removed.

On Thursday, September 3, 2015 at 11:08:22 PM UTC+2, Bob wrote:

[Patrice Chalin]

On Fri, Sep 4, 2015 at 2:36 AM, Günter Zöchbauer <gzo...@gmail.com> wrote:

On Friday, September 4, 2015 at 10:35:43 AM UTC+2, Lasse Reichstein Holst Nielsen wrote:

On Fri, Sep 4, 2015 at 10:09 AM, Günter Zöchbauer <gzo...@gmail.com> wrote:

Reified generics

I don't know the consequences but since Patrice explained to me that `<TypeA,TypeB>{}` is not the same than `new Map<TypeA,TypeB>()` I don't like reified generics much.

I would like to see that explanation - it should be exactly the same.

 

It's quite some time back, I guess it was a discussion on some Angular issue. 

AFAIR he mentioned `<TypeA,TypeB>{}` doesn't doesn't reify generic arguments. If you say it's the same I believe you of course ;-) and will have a better rest at night from now on.

I'm afraid I may have been misunderstood at the time. For the record, the discussion we had concerning the Angular Dart code base was about declarations of the form:

Map<A,B> m = {}

vs

Map<A,B> m = <A,B>{}

My statement was that the type arguments to {} are necessary if you don't want to end up with a runtime type of Map<dynamic,dynamic>. Some developers objected to the apparent need to unnecessarily "repeat" the type arguments when in fact they serve different purposes on the LHS vs. RHS. The type arguments on the LHS are part of the (optional) static type annotation whereas on the RHS they are part of the runtime call to the Map constructor.

Cheers,

Patrice

[kc]

On Friday, September 4, 2015 at 9:35:43 AM UTC+1, Lasse Reichstein Holst Nielsen wrote:

Maybe we should drop "extends" from the language, and replace it with auto-delegation.

Instead of "class C extends D { something(); }" you do:

   class C implements D as _d {

     final D _d;

     something();

   }

which automatically adds delegates for all members on D to call the same method on _d.

Then you don't need to have publicly visible generative constructors at all.

This more compositional approach looks interesting. There has been a turn against trad OO hierarchies.

K. 

[Günter Zöchbauer]

In this case this makes sense of course. 

I was quite confused about Dart type annotations back then - even more than now ;-)

Thanks for clarification and sorry for accusing you of making invalid statements!

I remember this discussion every time I write {}. Glad this finally is resolved :)

Cheers,

Günter

Mit freundlichen Grüßen

Günter Zöchbauer
gue...@gzoechbauer.com
+43 (699) 10 18 87 15

[Robert Åkerblom-Andersson]

Type annotations on the right

I think that if Dart 2.0 would go in that direction, would the ":" really be needed? I know Go is a different language in many ways but it works for them...

Yes, I do understand that it's easier to parse of course, but I feel that it could be parsed without the ":" as well... I can see that the "function as a variable" example might benefit from the ":" for better readability, but for variables (that are way more common), I find it somewhat in the way. It looks almost cumbersome to add types because of the extra typing, I might grow to like it, I don't know, but I don't really like looking at it right now..

I would not go as far as to say that I "HATE HATE HATE this" hehe, but I agree that it does look almost plain weird for normal vars and I think it would be off putting to a lot of devs... Some of you core language people might not really see this as you guys have seen so many different syntaxes, it's not that different if you have seen it before yourself, but lots of devs have never ever seen this type of syntax, where as I feel "just moving the type to the right" is a lot less unfamiliar. Sure any dev could get used to it, but Dart right now wants to add lots of new users not just adapt the existing ones...

As alternatives, while still keeping type annotations on the right (I think that alone is okay) I can think of three different ways to do it:

1. Simply remove the ":"

2. Make the ":" optional, then it can be added where needed for readability (like the function case) but not for simple String and int vars

3. Make the ":" required only for function variables, I know adding special cases might not be the "right way" in some sense, but it could maybe be a compromise worth doing in this case 

Something that was not mentioned in this meeting but that I read about earlier, was the idea of maybe making ";" optional. I think it was Bob that said basically that removing them completely might be a too big breaking change, but making them optional could be done since existing code would not break. 

I feel that there are a lot of similarities between the existing use of ";" and the proposed used of ":". It feels like both are added mostly to make parsing easier, while the truth is that the code could still be parsed quite good without them. I might be wrong, but it almost feel like a premature optimization considering how fast computers are today (no offense intended, I do way too much premature optimization myself as well). 

I think the idea of making both ";" and ":" optional could be worth considering as it would be simple to explain and understand... You can add them if you want for readability where needed or simply not use them at all. I understand the drawback of making something optional, it's not as "clean", but in this case I feel the compromise might be worth more to existing and new Dart developers.

Removing new

Yes, I was previously against this but after thinking some more and looking at examples I have switched over to the "yes camp". I now feel it would be a nice change if it was removed.

On Thursday, September 3, 2015 at 11:08:22 PM UTC+2, Bob wrote:

[Patrice Chalin]

On Fri, Sep 4, 2015 at 6:53 AM, Günter Zöchbauer <gue...@gzoechbauer.com> wrote:

... I was quite confused about Dart type annotations back then - even more than now ;-)

Thanks for clarification and sorry for accusing you of making invalid statements!

No worries. Dart is quite novel in its support for optional types and reified generics and, after years of programming in, say, Java, it takes some conscious effort at times to remind ourselves of the differences.

Cheers,

Patrice

[Brian Wilkerson]

Re: Fields final by default

I would be curious to know what percentage of fields (in existing code bases) are:

- explicitly marked as final

- implicitly treated like they were final

- not final

I know that we cannot get an accurate measure for the second item, but perhaps we could get a proxy for it, such as only including library private fields that are only assigned once.

Has anyone measured this?

Brian

[Rasmus Eneman]

--

You received this message because you are subscribed to the Google Groups "Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to core-dev+u...@dartlang.org.

Based on data from the 600 Dart repos with most stars on Github only 6,3% of all variables are declared as final and only 2,4% as const.

--

Rasmus Eneman

[Benjamin Strauß]

Reified generics

I actually like this feature although i don't use it very often. So i guess i won't miss it.

Type annotations on the right

I'm ok with this. Used ActionScript for years and recently started writing TypeScript code. The ':' is one more button to push but i think it's more readable.

Static methods / meta classes

Yes please! Leaning more towards metaclasses is always the right choice.

Constructor initialization lists

Never really used this just like const. Both can go away.

Parts

Completely useless in my opinion. Just use 'export'.

Prefixes / implied first class libraries

First class all the way!

Symbols

Again rarely used.

Fields final by default

I'm in.

Remove break, continue, and labels in favor of non-local returns

How about a compromise? Keep break, continue and labels but also add non-local returns. Users who would like to use them, could use them.

// normal return
return 'foo';

// non-local return
^return 'foo';

Uniformity of reference

I'm not sure how usefull this is in a language without mixfix notation. This has been mentioned before, but wouldn't this interfere with method extraction?

Removing new

Yes please, my first reacting was against this. But now i'm all in.

conclusion:

I feel like these new meetings are going forward in the right direction. Don't hesitate to innovate and take risks!

[Mike]

Thanks for that interesting post Bob.  Lots of nice-to-have ideas spring to mind!  My preferences would be:

Types on right:  No - keep them like they are please!  For me "final pi : int = 3" is hard to parse.  But also, I don't really see the benefit that would justify this change.

Parts:  I agree that they don't bring a lot to the language.

String v string:  I would capitalise int, bool etc.

Final by default: No.

Removing new:  No.

More radical ideas like dropping optional types: No.

But what about ... (yes I know some of this is just syntax)

More useful isolates e.g. ones that can take and return objects by value.

Nested classes

More useful Enums (by which I mean ability to add values like print(myEnum.ThirdPlanet); //earth

Tuples.

Functions able to return more than one result.

Ability to choose whether function parameters should be passed by value or reference.

Ability to initialise class members from class functions (not just from class constructors)

Structs.

Multi-dimensional array syntax (i.e. var myArray = new Array<int>(5,3);)

Syntax tidy up:

Swift's code looks cleaner than Dart's and avoids clutter.  Notably, it avoids semi-colons and doesn't use round brackets in for loops, switch statements and if blocks. Swift also has some nice syntax sugar e.g. you can say "for n in 0..<10 {" which in Dart is "for (int n=0;n<10;n++) {"

Any chance of some of that goodness?

Nothing to do with Dart 2.0:

Dart Editor:  Why, oh why?  What I really like about Dart is how easy it is to use.  Dropping Dart Editor (which I still use) was a mistake, in my view.  It was a great, free, easy to install and use, IDE and fantastic for introducing people to the language.  It improved hugely since it was first introduced, to the point where I find it a pleasure to use.  I have tried Atom and Intellij CE but Atom doesn't run programs and Intellij CE is overkill for what I want.  Maybe Atom will become the answer - I hope so.

[Bob Nystrom]

On Thu, Sep 10, 2015 at 11:24 AM, Mike <michael.s...@gmail.com> wrote:

More useful Enums (by which I mean ability to add values like print(myEnum.ThirdPlanet); //earth

This comes up a lot. I would definitely like to do something better here.

 

Swift's code looks cleaner than Dart's and avoids clutter.  Notably, it avoids semi-colons and doesn't use round brackets in for loops, switch statements and if blocks. Swift also has some nice syntax sugar e.g. you can say "for n in 0..<10 {" which in Dart is "for (int n=0;n<10;n++) {"

Any chance of some of that goodness?

I would be happy to see semicolons be optional in Dart. Most modern languages don't require them. Other syntax changes related to core statement forms are less likely. I think we get a lot of value out of sticking with the imperative statements users are familiar with from C/C++/JS/Java/C# and I don't think tweaking them adds that much value.

Now, adding new interesting statements is a different story. But for the for(), while(), and if() stuff users know and love, I think there's real value in familiarity.

Cheers!

- bob

[Lasse R.H. Nielsen]

I would definitely vote for removing parentheses around while/if/switch expression, but I fear it would complicate making semicolons optional - at least as long as loop bodies don't need to be block statements.

(And, just once more (for now) I'll tout what I want loops to be like:

   do { 

     body1;

   } while (expression) {

     body2;

   } else {

     afterwards;

   }

 

That is, both a do and a while block in the same loop, fixing the fencepost problem where you need to do some things n times and other things n-1 times.

It's basically equivalent to:

after: {

  while (true) {

    l1: {body1 [ break -> break after, continue -> break l1]}

    if (!(expression)) break;

    body2[break -> break after];

  } 

  afterwards;

}

I have written code like that :)

My only problem is that I want variables declared in the do block to be visible in the expression and while block, which breaks the normal scope rules :(

Even just the "else" block, only executed when the condition fails, and not if you break the loop (like in Python) would make some algorithms much easier to do.

As it is, I either write more convoluted code or uses labeled breaks (which seems to annoy the people reviewing my code).

/L

[Lasse R.H. Nielsen]

On Fri, Sep 11, 2015 at 4:52 AM, tatumizer-v0.2 <tatu...@gmail.com> wrote:

> "for n in 0..<10"

Why not just 

for (int n<10) {...}

The case is very common; if something deserves special syntax, this is the first candidate. Will become an instant hit.

I'd introduce ranges instead, then you could write:

  for (int n in [:10]) { ... }

A "range expression" is [ expr_opt : expr_opt ] and it evaluates to an iterable counting from the first value to (but not including) the last value. Omitting the first defaults to 0 and omitting the last generates an iterable counting towards infinity.

The compiler can recognize it when used as a literal in cases like this and generate a normal for loop.

(But then, I'd introduce  operator[:]  as well and use that as a lazy sublist/substring - and make the string version an efficient slice that doesn't copy unnecessarily, that would allow us to not pass "start, end" every place we want to pass a substring without creating the intermediate value).

 

Current syntax (borrowed all the way from C) is error-prone, especially if you have nested "for" loops: you copy&paste the first one and forget to change i to j somewhere.

When you (rarely) need a general case, use full syntax - it will also serve as indication that something unusual is going on here.

I can sympathize with that. If you have large idiomatic code sequences, then a shorthand makes sense.

  for (int i = 0; i < x.length; i++) { }

is a prime example. 

/L

[Günter Zöchbauer]

I'm in :)

[Günter Zöchbauer]

Dart doesn't have a notion of "package", "package" is from pub instead. 

I think there was something like `fried` mentioned recently. 

IMHO it would be a good solution to declare in one library which other libraries should be able to see private members (be a fried library). This would make part redundant.

It would also fix the problem that unit tests can't access private members which would be convenient for TDD.

On Sunday, September 13, 2015 at 5:29:34 PM UTC+2, tatumizer-v0.2 wrote:

WRT "parts": FWIW, I think the problem was originally misdiagnosed. Access to private variables of another library is often necessary. "part" feature tries to address this, but it's too restrictive, so it doesn't really solve the problem. 

When libraries x and y reside in the same package, there's no justification for imposing draconian restrictions on what each of them can see in a sibling library.

Maybe this should require special "show" clause in import statement like:

import "my_sibling.dart" show  _foo,_bar

BTW, we discussed this problem a couple of times on this forum already. Some ugly workarounds were mentioned as possible solutions.

 . 

[Günter Zöchbauer]

That's only for interpreting package uris but you are right, there might be only a small step in using this to check whether two libs are in the same package at least as long as a package uri is used in the import.

On Sunday, September 13, 2015 at 5:56:31 PM UTC+2, tatumizer-v0.2 wrote:
> > Dart doesn't have a notion of "package", "package" is from pub instead. 
>

> Effectively, there's a notion of package anyway. E.g. latest proposal on "packages" config deals with instructions to compiler on how to locate ... what?.

[Lasse R.H. Nielsen]

On Sun, Sep 13, 2015 at 5:56 PM, tatumizer-v0.2 <tatu...@gmail.com> wrote:

> Dart doesn't have a notion of "package", "package" is from pub instead. 

Effectively, there's a notion of package anyway. E.g. latest proposal on "packages" config deals with instructions to compiler on how to locate ... what?.

Dart doesn't have the notion of "same package". It resolves package: URIs to something and loads the individual libraries, but it doesn't have a concept of things being in the same package or not. That is, it doesn't know what "a package" is, just that there is "something package related" that it can load.

It's not hard to add - it's just checking whether the first path segment is the same - so if it makes sense to add some kind of "package privacy" to Dart, then it's definitely doable. It's just not necessarily a very good design since it only works for packages, it depends on *how* a file is imported (using a file: reference to a Dart file instead of a package: reference would make things break?), and not all Dart files come from packages (for example the dart: platform libraries don't).

A shared private namespace might make sense, but I don't think only applying it to packages is a good idea.

/L 'And I want "protected" first!'

[Günter Zöchbauer]

On Monday, September 14, 2015 at 9:08:46 AM UTC+2, Lasse Reichstein Holst Nielsen wrote:

On Sun, Sep 13, 2015 at 5:56 PM, tatumizer-v0.2 <tatu...@gmail.com> wrote:

> Dart doesn't have a notion of "package", "package" is from pub instead. 

Effectively, there's a notion of package anyway. E.g. latest proposal on "packages" config deals with instructions to compiler on how to locate ... what?.

Dart doesn't have the notion of "same package". It resolves package: URIs to something and loads the individual libraries, but it doesn't have a concept of things being in the same package or not. That is, it doesn't know what "a package" is, just that there is "something package related" that it can load.

It's not hard to add - it's just checking whether the first path segment is the same - so if it makes sense to add some kind of "package privacy" to Dart, then it's definitely doable. It's just not necessarily a very good design since it only works for packages, it depends on *how* a file is imported (using a file: reference to a Dart file instead of a package: reference would make things break?), and not all Dart files come from packages (for example the dart: platform libraries don't).

A shared private namespace might make sense, but I don't think only applying it to packages is a good idea.

/L 'And I want "protected" first!'

Great to hear you want this, so there is still hope :)

[George Moschovitis]

While we are talking about Dart 2.0 stuff, how about adding a @protected (and @private instead of '_') annotation, honored by DartAnalyzer etc?

[Erik Ernst]

About '_' as a prefix for private names: An important property of this approach is that both usages and declarations of names starting with '_' (that is, both "server" and "client" code using a private member) explicitly indicate their status as private, which makes the design fit well with the actual semantics of Dart, especially production mode.

If you wish to replace the '_' prefix by an annotation like `@private` on declarations of private members (and make the status as private invisible at usage sites) then the runtime must traverse a significantly larger amount of data when executing code that uses members, such that we avoid incorrectly granting access to a private member from a non-privileged position (e.g., for `@private`: from a different library). We would have to perform these checks with all usages of every member with a name which is used in any private declaration, which might in practice mean "all the time" (and which will certainly include all accesses to private members).

The checks would need to investigate the receiver object, find information about the relevant member (which calls for a certain amount of reflection), check whether that member has been declared as private (or protected, or whatever we have), and then check whether the constraints for the given level of protection are satisfied, and then throw some exception if they haven't.

The current ('_' based) approach, where renaming is used to make private names inaccessible outside their library, allows the runtime to simply perform the lookup without any privacy related checks at all. If the requested member is not present then we get a `noSuchMethod`, and this also applies in the case where library L1 uses a private name `_x` from library L2: The name `_x` was renamed to something secret (everywhere in L2), so the usage in L1 will not match, and hence there is no `_x` as seen from L1.

In summary, the `@private` approach is inherently costly if your runtime is powerful enough to support dynamic execution (which is required for Dart), so you may want to tolerate all the '_'s at usage sites after all, whether or not you find them ugly.  ;-)

On Sat, Sep 19, 2015 at 1:23 PM, Jan Mostert <jan.m...@gmail.com> wrote:

+1 for @protected and @private annotations, not a fan of the "_" for private variables.
Does Dart currently have any notion of protected variables / way to simulate protected variables?

On Sat, 19 Sep 2015 at 06:57 George Moschovitis <george.mo...@gmail.com> wrote:

While we are talking about Dart 2.0 stuff, how about adding a @protected (and @private instead of '_') annotation, honored by DartAnalyzer etc?

--

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

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--
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

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--

Erik Ernst  -  Google Danmark ApS

Skt Petri Passage 5, 2 sal, 1165 København K, Denmark

CVR no. 28866984

[Erik Ernst]

How should that transformer (which would be a compiler transformation implementing `@private` as syntactic sugar) be able to find the correct name _applications_ (aka usages, client sites, lookups, as opposed to declarations) using the name `test`, and transform them? For any given usage of `test` it might resolve (at runtime) to the `test` which is renamed to `_test`, or it might resolve to some other (public) `test` which will not be renamed. We must know with certainty that renaming is performed on the usages resolving to private members, and it is not performed on usages resolving to public members, but we don't always know the result of the dynamic lookups; and what do you want to do in the cases where it will actually resolve to a private member in some cases and a public member in other cases?

On Mon, Sep 21, 2015 at 11:09 AM, Jan Mostert <jan.m...@gmail.com> wrote:

Unless the @private annotation is just a transformer converting @private test; to _test, then there's only a penalty at compile time.

--
Jan Vladimir Mostert
janvladimirmostert.com

[George Moschovitis]

Personally, I am not interested in run-time privacy, '_' is OK for that.

I would like to use @protected, @private annotations at compile time, i.e. in the IDE. Just a hint for Dart Analyzer.

-g.

[Benjamin Strauß]

Will these language meetings also get public notes, now that the DEP and languages meetings are two different events?

Am Donnerstag, 3. September 2015 23:08:17 UTC+2 schrieb rnystrom:

Here's my notes from this week's now hour long meeting:

https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md

I mention this in the notes, but I want to call it out here. We're starting to discuss this vague notion of "Dart 2.0". We don't know what that means yet, and that means we'll be talking about all kinds of crazy radical ideas which may or may not come to pass.

[John Messerly]

definitely

--

You received this message because you are subscribed to the Google Groups "Dart Core Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to core-dev+u...@dartlang.org.

[Bob Nystrom]

Like John says, I certainly hope we share them widely.

But, at the same time, we haven't at all figured out any kind of venue or format for them, so it isn't clear what will get written down. I think a lot of this will end up being informal watercooler conversation kind of stuff in the different offices.

Cheers!

– bob

[Rasmus Eneman]

It would be interesting if they were recorded or performed via hangout.

Rasmus Eneman

[kc]

The C# team has a good process. Uses github and the Design Notes/Work List enables dev's to see what the team is considering - and give feedback.

https://github.com/dotnet/roslyn/issues/98

It's important to note that the C# design team is still in charge of the language. This is not a democratic process. We derive immense value from comments and UserVoice votes, but in the end the governance model for C# is benevolent dictatorship. We think design in a small close-knit group where membership is long-term is the right model for ensuring that C# remains tasteful, consistent, not too big and generally not "designed by committee".

Focused and fluid. The composition of the Dart lang team now looks good. So, maybe this combined with using core-dev for initial discussions with a prefix of 'Dart2: xxx'. Then raise something in github.

K.

Imo the problem of Dart 1.x was that the peopl