I think, compiler must disallow readonly if set definition exists:

class ValFut{  
  readonly Future? future{
    set{        
      //...
    }
  }
}

So, visibility of set will be expressed more explicit:

class ValFut{  
  Future? future{
    private set{        
      //...
    }
  }
}

I still think we should remove readonly entirely. Its a bit confusing in context of const and really doesn't save many keystrokes, is not consistent, and is less clear than just using the standard field protection semantics:

readonly Int x := 5
Int x := 5 { private set }

I agree. I decide to no more use readonly in own code.

This has been discussed previously, although I can't find the original discussion.

About two years I began removing readonly to use { private set } and didn't like where it was going (readonly is used very heavily).

Although I can live with it if virtually everyone agrees since it is a fairly big breaking change.

Other options would be to use a more meaningful keyword like getonly or something like that that indicated the field may change, but only the class itself has set access.

I'd prefer to keep readonly, although I'd favor renaming it to something more accurate. "Read only" sounds too similar to "immutable," at least to me.

I like "unmodifiable," although that's pretty long for a keyword.

unmodifiable sounds too similar to immutable

Well the most accurate keyword would be privateset but is that really better than not having a keyword at all? Best I can think of is getonly.

+1 to getonly or onlyget or perhaps even noset

I think anything besides privateset has misleading connotations. I'm not convinced we actually need a shortcut here - but I could live with privateset.

+1 for privateset. It's only two keystrokes more and has the advantage of not being confusing :)

If we are going to use privateset then we might as well as remove readonly altogether.

But is which is really better:

privateset Int x := 7
readonly Int x := 7
getonly Int x := 7

Int x := 7 { private set }

I've been conditioned to want to read a field using a keyword, so that just looks better to me. But it is sort of a hack that seems unnecessary.

+1 to intentional code:

Int x := 7 { private set }

Save your keyword for more important cases... and save an organ (the C++ committee used to say "You must donate an internal organ to add a keyword" :-)

This would do exactly what I expect

Int ans := 42 {private set}

whereas the readonly keyword would cause confusion as to what the (lack of) side-effects could be...

I was the confused one originally. See 1043.

And I still think that the readonly keyword is confusing at best. What about

@NoSet Int ans := 40

but I could easily live with the explicit version {private set}.

...Ok, I'm convinced. +1 to jettison readonly and make {private set } the sole way to do this.

Renamed from **[idea] disallow readonly and set for same field** to **Deprecate readonly keyword**

Promoted to ticket #1369 and assigned to brian

Not sure I am really sold on getting rid of the keyword entirely, but using {private set} seems just about almost as good. So seems like the same simple path is to just get rid of it.

Ticket resolved in 1.0.58

In the next build use of the readonly keyword will report a compiler warning, and support will be removed completely in build after that (1.0.59).

I feel like this is the right thing to do to clean the stage. However, I still feel there is some future feature to handle what seems to be a very common case where you want a "getter" method as part of your public API, but want to implement it using a field. The readonly keyword didn't actually implement this use case very well since the docs/reflections still exposed the slot as a field, not a method. Something to consider, but don't see any rush to figure it out.

I actually liked the read-only keyword, well it's functionality at least.

I see the point here and agree mostly, but I'd still like to have a way to make a field read-only without having to specify a private setter chunk of code.

I mean the private setter is ok, but it's a bit "heavy" to type and a bit weird looking to a Fantom newcomer IMO.

Anyway, just saying I'm not against removing read-only, but I'd like something almost as easy / clear to take it's place (Facet ?)

Well I am up for trying to come up with alternatives - but I personally think the use case is more than a convenience of creating a private setter. What I really want is something like that looks and works like a field, but is really this:

Str foo() { _foo }
private Str _foo

In the public docs and reflection I want foo to look like a method and not expose anything that a field was used to implement it.

Another use case that also seemed to fit was something like Java final - a field set in the constructor, but then the reference is fixed. Virtually every place I used readonly would also have been easily mapped to final.