I think it simply hasn't been implemented, but I am not sure here
because you could simply insert a `static assert` in there (and
probably have something like `hasInterface!(Interface,
YourStruct)`. Similarly multiple `alias this` is a request that
often comes up.

Interfaces are related to classes and not structs. Structs do not have
inheritance and do not implement interfaces in any way shape or form.
Classes and interfaces are always references, whereas structs never are, and
structs do not have virtual functions. Structs are either directly placed
where they are (be it on the stack or inside an object that contains them),
or they're placed on the heap and accessed via a pointer. As such, in D,
structs are fundamentally different from classes or interfaces.
If you want a function to accept multiple types of structs or classes which
share the same API, then use templates and use the template constraint to
restrict what the template accepts. That's what's done with ranges (e.g.
with isInputRange and isForwardRange).
- Jonathan M Davis

The problem is that interfaces are a runtime thing (e.g. you can
cast a class to an interface)
structs implement compile time interfaces via template duck
typing (usually enforced via an if()).
you could probably write a wrapper that introspected an interface
and enforced that all members were implemented.

On Friday, 29 December 2017 at 12:03:59 UTC, Mike Franklin wrote:
The problem is that interfaces are a runtime thing (e.g. you can cast a
class to an interface)
structs implement compile time interfaces via template duck typing
(usually enforced via an if()).
you could probably write a wrapper that introspected an interface and
enforced that all members were implemented.

I've actually thought about doing this to get rid of a bunch of if
qualifiers in my function declarations. `static interface {}` compiles but
doesn't [currently] seem to mean anything to the compiler, but could be a
hint to the programmer that nothing will directly implement it; it's a
compile-time interface. This would provide a more generic way of doing
stuff like `isInputRange`, etc.

On Friday, 29 December 2017 at 12:03:59 UTC, Mike Franklin wrote:
The problem is that interfaces are a runtime thing (e.g. you can cast a
class to an interface)
structs implement compile time interfaces via template duck typing
(usually enforced via an if()).
you could probably write a wrapper that introspected an interface and
enforced that all members were implemented.

I've actually thought about doing this to get rid of a bunch of if
qualifiers in my function declarations. `static interface {}` compiles but
doesn't [currently] seem to mean anything to the compiler, but could be a
hint to the programmer that nothing will directly implement it; it's a
compile-time interface. This would provide a more generic way of doing
stuff like `isInputRange`, etc.

On Friday, 29 December 2017 at 12:03:59 UTC, Mike Franklin
wrote:
The problem is that interfaces are a runtime thing (e.g. you
can cast a
class to an interface)
structs implement compile time interfaces via template duck
typing
(usually enforced via an if()).
you could probably write a wrapper that introspected an
interface and
enforced that all members were implemented.

I've actually thought about doing this to get rid of a bunch
of if
qualifiers in my function declarations. `static interface {}`
compiles but
doesn't [currently] seem to mean anything to the compiler, but
could be a
hint to the programmer that nothing will directly implement
it; it's a
compile-time interface. This would provide a more generic way
of doing
stuff like `isInputRange`, etc.

Or we could get signatures, which are even better still!

I was about to answer that interfaces could be used to define
duck types conformity models but this would be a poor and useless
addition, indeed, compared to signatures.

I've actually thought about doing this to get rid of a bunch
of if
qualifiers in my function declarations. `static interface {}`
compiles but
doesn't [currently] seem to mean anything to the compiler, but
could be a
hint to the programmer that nothing will directly implement
it; it's a
compile-time interface. This would provide a more generic way
of doing
stuff like `isInputRange`, etc.

On Friday, 29 December 2017 at 12:03:59 UTC, Mike Franklin
wrote:
The problem is that interfaces are a runtime thing (e.g. you
can cast a
class to an interface)
structs implement compile time interfaces via template duck
typing
(usually enforced via an if()).
you could probably write a wrapper that introspected an
interface and
enforced that all members were implemented.

I've actually thought about doing this to get rid of a bunch of
if qualifiers in my function declarations. `static interface
{}` compiles but doesn't [currently] seem to mean anything to
the compiler, but could be a hint to the programmer that
nothing will directly implement it; it's a compile-time
interface. This would provide a more generic way of doing stuff
like `isInputRange`, etc.

On Fri, 29 Dec 2017 12:39:25 +0000, Nicholas Wilson wrote:
I've actually thought about doing this to get rid of a bunch of if
qualifiers in my function declarations. `static interface {}` compiles
but doesn't [currently] seem to mean anything to the compiler, but
could be a hint to the programmer that nothing will directly implement
it; it's a compile-time interface. This would provide a more generic
way of doing stuff like `isInputRange`, etc.

I've actually thought about doing this to get rid of a bunch
of if qualifiers in my function declarations. `static
interface {}` compiles but doesn't [currently] seem to mean
anything to the compiler, but could be a hint to the
programmer that nothing will directly implement it; it's a
compile-time interface. This would provide a more generic way
of doing stuff like `isInputRange`, etc.

Is that simply because it hasn't been implemented or suggested
yet for D, or was there a deliberate design decision?

It's a design decision.
Look carefully at structs vs. classes here:
https://dlang.org/spec/struct.html
There is no virtual methods table (VMT) for structs, no
inheritance. Structs have value semantics. A variable with a type
of some interface implies it's a pointer, with reference
semantics and a VMT.

In C#, structs can inherit from and implement interfaces.
Is that simply because it hasn't been implemented or suggested
yet for D, or was there a deliberate design decision?
Thanks for your insight,
Mike

Is that simply because it hasn't been implemented or suggested yet for
D, or was there a deliberate design decision?

It was deliberate, but nothing says it can't actually be done. All an
interface call is, is a thunk to grab the actual object, and then a call
to the appropriate function from a static vtable. It's pretty doable to
make a fake interface. In fact, I'm pretty sure someone did just this, I
have no idea how far back in the forums to search, but you can probably
find it.
Now, it would be nicer if the language itself supported it. And I don't
see any reason why it couldn't be supported. The only issue I think
could be an ABI difference between member calls of structs and classes,
but I think they are the same.
-Steve

Is that simply because it hasn't been implemented or suggested
yet for D, or was there a deliberate design decision?

It was deliberate, but nothing says it can't actually be done.
All an interface call is, is a thunk to grab the actual object,
and then a call to the appropriate function from a static
vtable. It's pretty doable to make a fake interface. In fact,
I'm pretty sure someone did just this, I have no idea how far
back in the forums to search, but you can probably find it.
Now, it would be nicer if the language itself supported it. And
I don't see any reason why it couldn't be supported. The only
issue I think could be an ABI difference between member calls
of structs and classes, but I think they are the same.
-Steve

Don't forget to implement boxing/unboxing and then write a long
blog post on all the dangers and negative effects of using
interfaces with structs.