NOTE: It's just an idea, not a proposal.

I'm a big fan of clarity in design.

Clarity is what makes your design understandable and maintainable.

'implement' - implements an abstract/interface method - First-time definition

'override' - overrrides a concrete base method - Replaces or extends existing logic


interface Clickable
{
  void onClick();
}

class Component
{
  void render()
  {
      writeln("Rendering generic component");
  }
}

class Button : Component, Clickable
{
  implement void onClick()
  {
      // First-time implementation of Clickable.onClick
      writeln("Button clicked!");
  }

  override void render()
  {
      // Overrides Component.render
      writeln("Rendering a button");
  }
}

---- currently you can do it this way in D, and it provide very little clarity at all.

interface Clickable
{
  void onClick();
}

class Component
{
  void render()
  {
      writeln("Rendering generic component");
  }
}

class Button : Component, Clickable
{
  void onClick()
  {
      writeln("Button clicked!");
  }

  override void render()
  {
      writeln("Rendering a button");
  }
}

On Friday, 31 October 2025 at 22:58:04 UTC, Peter C wrote:
>

or even (a C# like explicit implementation would be a nice option to have in D:

interface Clickable
{
  void onClick();
}

class Component
{
  void render()
  {
      writeln("Rendering generic component");
  }
}

class Button : Component, Clickable
{
  void Clickable:onClick()
  {
      // First-time implementation of Clickable.onClick
      writeln("Button clicked!");
  }

  override void render()
  {
      // Overrides Component.render
      writeln("Rendering a button");
  }
}


--- And when it becomes even more confusing:

interface Isomething
{
  void someMethod();
}

class Base
{
  void someMethod() { }
}

class Derived : Base, Isomething
{
  override void someMethod() { } // ??

// Error: Method 'someMethod' matches both a base class and interface signature. Use override or explicit interface implementation to clarify."

}

On Friday, 31 October 2025 at 22:58:04 UTC, Peter C wrote:
> 'implement' - implements an abstract/interface method - First-time definition
>
use @implement and build your own checker if you need this.

> I'm a big fan of clarity in design.
yeah, the java exception lists were that too. turns out people hate useless clutter and extra work.

On Friday, 31 October 2025 at 23:39:29 UTC, Zealot wrote:
> On Friday, 31 October 2025 at 22:58:04 UTC, Peter C wrote:
>> 'implement' - implements an abstract/interface method - First-time definition
>>
> use @implement and build your own checker if you need this.
>
>> I'm a big fan of clarity in design.
> yeah, the java exception lists were that too. turns out people hate useless clutter and extra work.

Java's `throws` is kinda cute I think.

On Friday, 31 October 2025 at 23:36:57 UTC, Quirin Schroll wrote:
> On Friday, 31 October 2025 at 22:58:04 UTC, Peter C wrote:
>> NOTE: It's just an idea, not a proposal.
>>
>> I'm a big fan of clarity in design.
>>
>> Clarity is what makes your design understandable and maintainable.
>>
>> 'implement' - implements an abstract/interface method - First-time definition
>>
>> 'override' - overrrides a concrete base method - Replaces or extends existing logic
>
> This is a good idea for nomenclature in documentation, but it doesn't work with the language. You can implement an interface method by inheriting from a class that defines the method without the base class implementing the interface.

ok. interesting...

interface IGreeter
{
    void greet();
}

class Base
{
    void greet() {}
   // Really, there should be a complier error here.
   // e.g "Error: Method 'greet' matches both a base class and interface signature."
   // so ok...what to do here?? remove or rename?
   // I don't think Base should sucessfully compile under this circumstance.
}

class Derived : Base, IGreeter
{

}

On Friday, 31 October 2025 at 23:39:29 UTC, Zealot wrote:
> On Friday, 31 October 2025 at 22:58:04 UTC, Peter C wrote:
>> 'implement' - implements an abstract/interface method - First-time definition
>>
> use @implement and build your own checker if you need this.
>
>> I'm a big fan of clarity in design.
> yeah, the java exception lists were that too. turns out people hate useless clutter and extra work.

I kinda meant 'clarity to avoid ambiguity', not clarity to create clutter and extra work.

On Friday, 31 October 2025 at 23:49:06 UTC, Peter C wrote:
> On Friday, 31 October 2025 at 23:36:57 UTC, Quirin Schroll wrote:
>> On Friday, 31 October 2025 at 22:58:04 UTC, Peter C wrote:
>>> NOTE: It's just an idea, not a proposal.
>>>
>>> I'm a big fan of clarity in design.
>>>
>>> Clarity is what makes your design understandable and maintainable.
>>>
>>> 'implement' - implements an abstract/interface method - First-time definition
>>>
>>> 'override' - overrrides a concrete base method - Replaces or extends existing logic
>>
>> This is a good idea for nomenclature in documentation, but it doesn't work with the language. You can implement an interface method by inheriting from a class that defines the method without the base class implementing the interface.
>
> ok. interesting...
>
> interface IGreeter
> {
>     void greet();
> }
>
> class Base
> {
>     void greet() {}
>    // Really, there should be a complier error here.
>    // e.g "Error: Method 'greet' matches both a base class and interface signature."
>    // so ok...what to do here?? remove or rename?
>    // I don't think Base should sucessfully compile under this circumstance.
> }
>
> class Derived : Base, IGreeter
> {
>
> }

oops.

interface IGreeter
{
    void greet();
}

class Base
{
    void greet() {}
}

class Derived : Base, IGreeter
{
   // "Error: class Derived inherits a base class method that matches IGreeter.greet(). Use an explicit interface declaration to implement Greeter.greet()"

}

On Friday, 31 October 2025 at 23:36:57 UTC, Quirin Schroll wrote:
>
> ..
> You can implement an interface method by inheriting from a class that defines the method without the base class implementing the interface.

ok. that took me a while to get my head around ;-)

--------------------------------
interface IsomeInterface
{
    void someMethod();
}

class Base
{
    void someMethod() { } // virtual by default in D.
}

class Derived : Base, IsomeInterface
{
  // Note: no mention of void someMethod() anywhere.
}
-------------------------------

ok. now we have the 'accidental implementation' problem.

The compiler really should produce an error message here, in relation to Derived:

> Error: 'Base.someMethod' signature conflicts with 'IsomeInterface.someMethod' signature. Add an explicitly declared void someMethod() in Derived, to resolve this ambiquity.

Fortunately in D, 'override' is now required to override a base class method.

So now, the programmer *must* do either of these things:

(1)
class Derived : Base, IsomeInterface
{
  // NOTE: D doesn't have an 'implement' keyword for implementing an interface method.

  void someMethod() {} // implementing the interface contract here

}

(2)
class Derived : Base, IsomeInterface
{
  override void someMethod() {} // overiding the virtual member inherited from Base.
}

Either way, the compiler is now satisfied that you have resolved the 'accidental implementation' problem.

I don't expect D to make a change here, but this is how I would have expected a compiler to behave in any case.

I think the Carbon language may have resolved this.

On Saturday, 1 November 2025 at 06:41:57 UTC, Peter C wrote:
> ok. now we have the 'accidental implementation' problem.
>

There is nothing "accidental" there - you have made the decision to inherit from Base, and should know what that means!