use the `function` keyword to declare getters

I think that if we decide to endorse #6424, it’ll be best to use the function keyword to declare getters. It’s just way more regular:

function foo()() => "";
function bar() => "";
function baz => "";

and

function foo()()
{
    return("");
}
function bar()
{
    return("");
}
function baz
{
    return("");
}

as opposed to

function foo()() => "";
function bar() => "";
value baz => "";

and

function foo()()
{
    return("");
}
function bar()
{
    return("");
}
value baz
{
    return("");
}

You’d still be able to do everything you do today (i.e. refining variables with getter+setter and vice‐versa).

[gavinking]

Well I think @lucaswerkmeister already put it pretty well. A getter is not a function. Simple as that.

[lucaswerkmeister]

You say that “a getter is not a function”, but what is a function? To me, it’s a set of ordered instructions organized to performed a task, a definition into which getters neatly fall.

I would call that a “procedure”, perhaps. A function takes parameters, can return a result, and can have side effects. A value cannot take parameters, and if it has side effects that aren’t idempotent, you’re doing something wrong. Getters should not perform a task – they should get a value, and nothing else!

Ceylon also never just stores a value in a memory location. Even a non-lazy member, like just shared Integer i = 1;, always compiles to a getter (and, if variable, a setter). This makes it possible to switch from eager to lazy values without breaking binary compatibility. Changing to a function, on the other hand, is a breaking change. The point is that, as a user, you don’t need to know if a value is eager, lazy, or a getter. You just use it, and trust that it’s implemented reasonably.

Dunno. I feel like I’m just repeating myself, but this is really important: You shouldn’t think of getters like functions. You can do this, yes:

Integer x {
    print("x was accessed");
    return 1;
}
Integer y {
    execDB("DROP DATABASE");
    throw AssertionError("you nasty person, you");
}
String z {
    return randomBool() then "foo" else "bar";
}

but that’s not what getters are supposed to do. As a user of your class, I expect that these are logically equivalent, though the first one may or may not be less efficient:

for (i in 1:10) {
    print(foo.bar);
}
value bar = foo.bar;
for (i in 1:10) {
    print(bar);
}

If you want to treat getters just like other functions, then I’d say the logical consequence would be to drop them altogether, in favor of functions, not to change their syntax. But then you lose an important and convenient language feature: the ability to define reasonable getters.