Removed Type-Defect label.
Added Type-Enhancement, Area-Language, Triaged labels.

This comment was originally written by @seaneagan

To expand on const methods, in addition to regular methods, they could also support:

// getters
const int get foo => new Foo(x);
static const Foo get foo => new Foo(x);

// final instance fields (implied instance getters)
const Foo foo;

// operators
const operator + (int other) => int value;

This would remove all the special cases from the language spec about what can be considered a constant, and instead that can be seen directly in the api docs of dart:core, and any other lib which wants to define const methods.

This comment was originally written by grant.js...@gmail.com

Would it not be great if, instead of using:
new Foo(x);
to create/instantiate a constant object
const Foo(x);
was used instead.
Swapping out out the "new" keyword with "const" keyword for instantiation will immediately communicate that we are creating a constant.

This comment was originally written by @zoechi

Thats how is is currently.

Const was very carefully limited in Darr,by design. We chose not to introduce const methods/getters etc. with notions of constness propagating. This is always subtle (well, a rat hole really). The cases where things are constant are explicitly defined in the spec and we want it that way.

Set owner to @gbracha.
Added WontFix label.

This comment was originally written by @seaneagan

Hi Gilad,

The limitedness of the const feature in dart currently limits the ability to use (and predict when one will be able to use) the dependent language features of metadata, default values, and canonicalization.

This issue proposes two simple, and backward compatible extensions that together pretty much completely solve this problem in my opinion:

1. Make const (and new) optional at call sites, inferring constness from the top-level call-site. This at the very least adds the ability to reference other "potential constants" from the initialization list of the only current declaration allowed to be defined as constant, i.e. generative constructors, which is a pretty big pain point currently. An added bonus is terseness of constructor call-sites.

2. Allow other things besides generative constructors, i.e. normal methods, getters, and factory constructors which merely return an expression (using =>) and instance fields to be explicitly declared const so that users can have the same luxury to define constants as the core libraries do (by virtue of being explicitly specified in the language spec). Note that it is then very easy to determine when constness should propogate here, i.e. when calling an explicitly declared const method, getter, or field. An added bonus is simplification of the spec, and documentation of constness directly at the declaration site (as opposed to the spec) which makes it easier to integrate into tooling such as API docs and refactoring.

Can you please address both of these extensions separately, and also why you consider them a rat hole, i.e. what cases do they leave unaddressed? Why is restricting the ability to define constants a goal?

Thanks!

This comment was originally written by @zoechi

To 1) I wonder if it's possible in this case to see (as a developer) when const is used. What when I know something should be const but something not obvious at callers site prevents it? When I can't explicitly declare it const I can't get a warning.

When something can be const but I don't want it to be const because I want to change it later, how can I prevent that? Just because something can be used in a const context doesn't mean I always want to.

This comment was originally written by @seaneagan

Yes, so when you declare something to be const (currently only constructors
support this) you are not declaring that it must always be invoked as a
constant, i.e. callers can use "new" as well. So thus the calls you make
from that constant declaration (currently only constructor initialization
list items) should not use "new" or "const" (and thus constructors
including [] and {} can't currently be used at all), since we don't know
whether the call-site of the current invocation of the thing we are
declaring is using "new" or "const", so if we leave it out, then it can
just be inferred. It would work the same way with 2) i.e. const methods,
getters, operators, factory constructors, and fields.

I think there already is a separate issue for (1).

As for extending the number of constructs that can be marked const (item 2). It is a slippery slope. The demands never end. Can I make an instance method constant, and if not, why not (we already had this debate for instance variables)? And now we need to execute arbitrary code at compile time. What if it contains loops? Just restrict them to expressions? Can they be recursive? Directly or indirectly? Can they use conditionals? For every limitation, someone comes up with a use case, an example that looks plausible in isolation.

There are answers to all these things, but complexity is a bad thing. Ultimately we make a judgement call as to how far we should go and which directions are worth investing in.

Are you thinking of issue #5680 ? That's to remove new. I want it optional to keep the new crowd happy but program in peace for myself withoutnew.

This comment was originally written by @seaneagan

Great questions:

Can I make an instance method constant, and if not, why not (we already had this debate for instance variables)?

Yes, const instance method calls would only be considered const when the receiver and all arguments are const of course. It would be at least a warning if not error when the class does not have a const constructor:
    
    class Foo {

      const int x;

      const Foo(this.x);
      
      const m(int y) => x + y;
    }
    //...
    print(const Foo(1).x); // Same as 1
    print(const Foo(1).m(2)); // Same as 3

Notice that both the instance variable and method must be explicitly marked const.

And now we need to execute arbitrary code at compile time. What if it contains loops? Just restrict them to expressions?

Yes, just expressions. That would solve any use case I've ever had.

Can they be recursive?

I guess if you do allow recursion, then you'd need to detect infinite recursion during compilation by setting a max stack depth. I'm curious if anywhere else in dart already requires this.

I rest my case.

You should be able to see how far from trivial or straightforward the issues are, and how vast the gap is between showing an example and actually working out what the rules are and implementing it. This clearly qualifies as a rathole.

const may be a rathole but can we at least make new optional?
Shall I open a new issue on this?

"optional new" was http://dartbug.com/18241 - it's closed as WontFix.

That's this same issue. But it includes making const optional which appears to be a mess to change. I'm talking about only making new optional and leave const the way it is.

This comment was originally written by @richardeakin

re optional new:

I think Gilad is clearly not interested, as it has been debated to quite some extent, though I would urge the dart team to reconsider based on popular voice. I for one think that many expressions would be much clearer if the weren't plagued with new statements for simple objects, but I come from a C++ background where new is rarely used.

const, well I like const too but that is a different topic altogether! It should be discussed separately.

I created a new discussion for new at issue #20750