There was a semi-proposal on a thread last week, which no one really repsonded to.

Would you guys like to omit the const keyword on a static field:

// today
const static Int x := 5

// proposed, const is implied
static Int x :=5

I think at this point, there will never be non-const static fields. So this seems like a pretty safe change - its just a matter of taste: consistency versus verbosity.

What's the vote?

I don't have a real preference. On one hand const reinforces the requirement for static fields when reading/writing code. But on the other hand, since thats always the rule, seems like you could leave it off.

I'm big on the Don't be Redundant principle. But it just occurred to me, static could be the redundant one.

static Int a := 1 
const  Int b := 2

both mean the same thing, but the second seems more clear (to me) about it.

How about, const is preferred and implies static const; static by itself is a warning, since that one's guaranteed to surprise new Fan users.

static Int a := 1

const Int b := 2

These actually are not the same:

class Foo
{
  new make(Int v) { this.v = v }
  const Int v
}

a := Foo(3)
b := Foo(5)
a.v != b.v

static Int a := 1
const  Int b := 2

both mean the same thing

Or maybe they don't. Now I'm confused. :-)

Sorry, too early in the morning.

Yeah, const works differently than say C#. In Fan const just means immutable, but not necessarily static. But since Fan does not allow any mutable shared state, static fields must be const.

Allow users to leave out the const keyword since it's implied. Much like when you create an interface in Java, it's implied that every method is public, but you can still specify the keyword to reinforce that notion.

I agree with JohnDG, in making const optional for static fields.

Much like when you create an interface in Java, it's implied that every method is public,

I've used Java since pre-1.0, and I actually just learned this - so I am not sure that was a good thing.

So my thought if is we make const implied by static, then it is a compiler error to include both - I prefer to enforce just one way to do it.

I've used Java since pre-1.0, and I actually just learned this - so I am not sure that was a good thing.

I actually did know about this but I've always added the public modifier anyway.

So my thought if is we make const implied by static, then it is a compiler error to include both - I prefer to enforce just one way to do it.

Sounds good to me. I'm fine with optionally allowing const to make code more intentional to the uninitiated, but I'd be equally fine with disallowing it as redundant on a static.

So my thought if is we make const implied by static, then it is a compiler error to include both - I prefer to enforce just one way to do it.

In that case, I would prefer not to make const implied by static. It's strange to me that adding const on a const field would result in a compiler error -- so it's better to mandate it.

I vote for omitting const on static fields.

I'm up in the air. But if it is changed, I agree to make using const a compiler error. People would then learn quickly enough what static fields mean.

I'd raise my hand for the static const option. It's not terribly long, and once you've written it down, it's not likely to ever change in the code.

It seems to me that slot modifiers should be explicit in the same way that slot types must be. Take this example

class Foo
{
  Str x
  new make() { x = "asdf" }
}

Even though the compiler could easily infer the type of x to be Str, we require it to be explicit. I think modifiers should also fall within this policy.

No clear winner here.

I'm going to say lets leave it explicit - you have to specify both static and const. It isn't a huge deal to have the extra const and having it explicit keeps it consistent.

Fine with me.

I just got the same problem. I have no chance to create a static field:

1.  public static Tuplet NORMAL := Tuplet();
2.  public static const Tuplet NORMAL := Tuplet();
3.  public static readonly Tuplet NORMAL := Tuplet();
pre>

1. Static field 'NORMAL' must be const
2. Const field 'NORMAL' has non-const type 'alphaTab::Tuplet'
3. Static field 'NORMAL' must be const

what to do?

You to make Tuplet a const class.

If you can't do that (it needs to be a mutable), then you can't make it a static.

Ignore...

If I'd make Tuplet a const class, all other fields within this class need to be const too but I have fields which need to be changed during runtime. Here's my full class:

/**
 * represents a n:m tuplet
 */
plass Tuplet
{
  public static readonly Tuplet NORMAL := Tuplet();
  
  public Int enters;
  public Int times;
  
  public new make()
  {
    enters = 1;
    times = 1;
  }
  
  public Void copy(Tuplet tuplet) 
  {
    tuplet.enters = enters;
    tuplet.times = times;
  }
  
  public Int convertTime(Int time)
  {
    return (Int)(time * times / enters);
  }
  
  public override Bool equals(Obj? obj)
  {
    if(obj == null) return false;
    if(obj == this) return true;
    if(!(obj is Tuplet)) return false;
    Tuplet tuplet := (Tuplet)obj;
    return enters == tuplet.enters && times == tuplet.times;
  }
    
  public Tuplet clone(SongFactory factory)
  {
    Tuplet tuplet := factory.newTuplet();
    copy(tuplet);
    return tuplet;
  }
}

Sorry I didn't post this earlier. See this discussion for my take on a similar problem, with some interesting solutions. It'll give you great insight into Fantom's Actor model of concurrency, if nothing else.

If I'd make Tuplet a const class, all other fields within this class need to be const too but I have fields which need to be changed during runtime. Here's my full class:

In general the best solution to this is to allocate new instances when you want to change something. As a general philosophy I like to make any "data structure" class like this immutable.