carbon-language / carbon-lang

Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
http://docs.carbon-lang.dev/
Other
32.25k stars 1.47k forks source link

Proposal: Replace the `extends` keyword with just `:` #2072

Open CXCubeHD opened 2 years ago

CXCubeHD commented 2 years ago

Proposal

extends looks and is boilerplate, replace it with : instead.

class MyClass : MyOtherClass
{
    ...
}

Additonal inheritance (sometimes in the future) or implementation statememts (of interfaces) are seperated using ,

class MyClass : MyOtherClass, MyInterface
{
    ...
}

Thanks for reading, change it while you still can!!!!

Edit

I cannot answer to any comments because I was blocked for NO REASON in #2071

Thank you jonmeow 👏👏👏, very good job, I hope they pay you good money for your good work 👏

Response to Comments

Remember that Java eliminated the concept of multiple inheritances to avoid conflicts between members of different parent classes should there exist any common attributes or functions.

@vinsdragonis I can speak for many people when I say that the : syntax is a much nicer and less verbose. Other languages like C# or Kotlin have this syntax as well and they also don't have multi inheritance.

Edit: Also, you need to look it in this way: Why do you write fn instead of function in function declaration statements? Why do you write var instead of variable? Simple: less verbosity.


Elsewhere in Carbon's syntax, we use name: type to mean that the type of name is type. Using class Derived : Base would deviate from that, because the type of the name Derived is the type-of-type Type, not the class type Base, so there's a risk of making our syntax inconsistent if we follow this proposal.

@zygoloid Kotlin also has a var name: type and a class Class : Base syntax and it works very well so why also not implement that less verbose syntax.

vinsdragonis commented 2 years ago

Hey @CXCubeHD! While the idea of using a colon seems to adhere to the C++ syntax and can be a good choice for people who would transition to carbon from C++ in the long run, I think we should avoid inheriting from more than one parent class. Remember that Java eliminated the concept of multiple inheritances to avoid conflicts between members of different parent classes should there exist any common attributes or functions.

However, implementing interfaces doesn't seem to cause such an issue. So to summarize, the idea has merit if not for that one drawback.

nacaclanga commented 2 years ago

extends works IMO better, when you only allow a single class to be specified here, while : works better with a "bounded by mixins point of view. https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/generics/overview.md#interfaces descibes interfaces to act not like base classes, however the language is supposed to also support mixins. A solution to this should consider, how mixins are suposed to be implemented.

zygoloid commented 2 years ago

Elsewhere in Carbon's syntax, we use name: type to mean that the type of name is type. Using class Derived : Base would deviate from that, because the type of the name Derived is the type-of-type Type, not the class type Base, so there's a risk of making our syntax inconsistent if we follow this proposal.

Another consideration is that using a keyword like extends allows us to move the base specifier into the class body without changing its syntax:

class Derived {
  var n: i32;
  extends Base;
  var m: i32;
}

... and in so doing, we can give the developer control over where in the class layout the base class is positioned. Such syntax might also be useful for mixins. This syntactic freedom is already used to some extent in interface declarations, where extends declarations are permitted within the interface body.

On the other hand, using a : syntax will certainly be more familiar for developers coming from C++.

github-actions[bot] commented 1 year ago

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time. This issue is labeled inactive because the last activity was over 90 days ago.