Slice: switch from C-style to Pascal-style

[bernardnormier]

The Slice language is currently a C-style language, with:

• return values specified on the left hand-side of an operation (e.g. int op())
• parameter and data member definitions use the Type name syntax

This is a proposal to switch to a Pascal / Rust / Swift -like syntax:

• return values would move to the right handside after an arrow as in rpc op() -> int
• parameters and data members use the name: Type syntax like in Rust (TBD use comma or semicolon for data member separators?)

For example:

// existing Slice
interface Greeter
{
    string greet(string message);
}

becomes:

interface Greeter
{
    rpc greet(message: string) -> string;
}

There are two advantages to switching:

• the Pascal style allows to qualify an operation or a parameter / return without ambiguity, e.g.

  idempotent rpc op() -> int; // op is idempotent, not its return value
  
  rpc op() -> stream int; // op returns a stream of int; op itself is not "streamed"

• the Pascal / Swift / Rust style is now the prevalent style, used by all modern languages, in particular those we want to support in the near future (Rust, TypeScript, Kotlin, Swift, Go).

The only C-style language we want to support with IceRPC is C#.

Note that Protobuf is an unusual mix of both styles: message definitions use C-style while rpc definitions use Pascal style.

[externl]

Sounds good to me.

1. I prefer , for data member separators.
2. I don't think we need the rpc keyword. Not all languages do this. For instance, Go goes not use func in interface definitions.

Another benefit of this style is that it's not longer ambiguous if operation attributes are attached to the operation or the return value.

[InsertCreativityHere]

return values would move to the right handside after an arrow as in rpc op() -> int

I'm in favor of adopting the arrow syntax. I think it's clear what is attached to the function and what is attached to the return type this way (and it's easier to parse!), but I don't think the rpc is necessary here. Only operations can appear in an interface, so there's no ambiguity here that we'd need a keyword to fix.

TBD use comma or semicolon for data member separators?

I think I also prefer ,. Structs are closer to things like tuples and parameters, which already use ,.

Otherwise, I agree! I think this syntax is an improvement over our current Slice syntax.

[pepone]

I like this new syntax but I agree with Austin that rpc keyword seems unnecessary.

I think we should also use comma for struct/class/exception fields separator and allow a trailing comma

struct Foo {
   x: int,
   y: int, // Trailing comma should be accepted
}

[InsertCreativityHere]

The style was changed in #71 and https://github.com/zeroc-ice/icerpc-csharp/pull/709