Comment author: @dra27

I think it is fair to say that no decision in the language was taken with a view to making any part of the language less usable.

In the first instance, there are already two ways of writing what you want:

class c =
  let r = ref [] in
  let () = r := [1] in
  object
  end

and (admittedly only for your specific example):

  class c =
    let r = {contents = [1]} in
    object
    end

There are also initializer, though the semantics are of course different (evaluate at object creation rather than class definition):

class c =
  let r = ref [] in
  object
    initializer r := [1]
  end

Does generalising class definition to be a sequence ending in a object really add much-needed expressive power?

Comment author: @dra27

For the second case, I expect the class sub-language was simply not considered when let open was added to the language - perhaps Alain has thoughts on this? It seems like a reasonable thing to add to me.

Comment author: mookid

I am aware of this workaround.

My point is that in most cases (recursive definition aside), changing an object definition to a class definition should be a matter of changing one "let" to "class". I consider any additional required change as a failure.

And contrary to some other dubious syntactic characteristics (in particular,"f -1" not being "f (-1)", for instance), fixing it would probably not break existing code.

Comment author: @yallop

There's some discussion of "let open" for classes here:

#6271

Comment author: @alainfrisch

#1249

Comment author: @alainfrisch

"let open" as been added.

For sequencing, there exists a trivial and local syntactic rewriting ("e; ce" => "let () = e in ce"). I don't think this deserves any particular treatment at the language level.

A local module binding (and module patterns) would seem be more useful, but Jacques mentions in #6271 that this would be quite difficult (presumably to ensure that types from the module don't escape).