struct methods syntax

[renlite]

Hi,

have you considered to implement the struct methods like in rust? IMO this would improve the readability of functions a lot and reduce repetition. (please see example)

// current ---

fn String String.trim_left(string, String to_trim = "\t\n\r ")
{
    usz start = 0;
    usz len = string.len;
    while (start < len && char_in_set(string[start], to_trim)) start++;
    if (start == len) return string[:0];
    return string[start..];
}

fn String String.trim_right(string, String to_trim = "\t\n\r ")
{
    usz len = string.len;
    while (len > 0 && char_in_set(string[len - 1], to_trim)) len--;
    return string[:len];
}


// new ---

impl String
{
    fn String trim_left(string, String to_trim = "\t\n\r ")
    {
        usz start = 0;
        usz len = string.len;
        while (start < len && char_in_set(string[start], to_trim)) start++;
        if (start == len) return string[:0];
        return string[start..];
    }

    fn String trim_right(string, String to_trim = "\t\n\r ")
    {
        usz len = string.len;
        while (len > 0 && char_in_set(string[len - 1], to_trim)) len--;
        return string[:len];
    }
}

[nmsobri]

please no.. its unnecessary complicated and it does not improve readability nor does it reduce repitition.. the only thing it add is extra block of indentation.. current way of declaring methods is the best way to do it and its allow extension function like in Kotlin

[renlite]

Kotlin: is "type last" -> extention functions have less impact on readability.
Repetition: Expample only with two struct methods -> 10 and more ... String. String. String. String. ...
Extention functions in C3 with impl syntax/namespace: Don't know if still possible.
Identation: Says, where it belongs to(struct) at first glance.
I think it would not break the design of C3 and stay simple.

[nmsobri]

String. String. String is barely repititive. It give u context which entitiy the function belongs to

Extention functions in C3 with impl syntax/namespace: Don't know if still possible.

Its possible.. its only need to be handle at lexing and parsing level.. But it really unnecessary. Its add nothing. String. already give you the context

I think it would not break the design of C3 and stay simple.

It does not. But having so many way to do one things just add confusion to new user coming to the language.

[renlite]

I agree only one way should be possible not both: "current" or "new" -> Readability and structure of code ?

[lerno]

It's deliberately not inside of such a construct. Usually something like that is constructed to emphasise that the methods form a closed set. That is, method additions are closed. C3 is completely the opposite, where you can add methods to anything anywhere. Want to add a function to int? Be my guest! Want to add macros generically to array types? That's fine too. Etc

Even if it can be made to work, there is the clear downside when extending:

impl Foo
{
  fn void abc(self) { ... }
}

When I could have written

fn void Foo.abc(self) { ... }

So in terms of "nudging", having "Impl" encourages thinking of methods as a closed set, whereas the current encourages thinking of methods as an open set. The latter is desirable.

On top of this it also introduces a namespace-y construct to the C syntax, which is a complexity cost. Again, if the methods were closed, then this would make sense, but they're not.

[renlite]

Although the syntax is still a bit confusing (readability) in this case it makes sense. Thanks for exmplenations.