Compile-time Interfaces

"Jérôme M. Berger" jeberger at free.fr
Mon Nov 28 05:11:35 PST 2011


Jérôme M. Berger wrote:
> =====================================================================
> 
> 	How would they work?
> 
	On second thought, I think the "static" keyword (or whatever)
should be added to the function declaration instead of the interface
declaration. In effect, it would mean "I don't care what the actual
type of this argument is provided that it provides the methods
declared in the interface". There are two reasons why this is better:

- I believe it is clearer for the user who looks at the function
prototype, that way he sees immediately that something special is
going on;

- The lowerings I described can be done in the parsing pass without
any semantic knowledge about the interfaces.


	The text below is the same as my previous description with the
differences that compile-time interfaces are now standard interfaces
and the change is in function declarations.

=====================================================================

	How would they work?

	It might be possible to implement compile-time interfaces with a
simple lowering. Somebody who knows more about the compiler
internals will have to say how feasible this idea is.

Interface definition
====================

The interface could be defined as a standard template interface:

interface(T) Range {
    void popFront() const;
    @property bool empty() const;
    @property T front();
}

Class definition
================

There would be nothing special when defining a class:

class IntRange {
    void popFront() const;
    @property bool empty() const;
    @property int front();
}

Note that the class does not need to inherit from the interface.

Function definition
===================

Simple case
-----------

A function which uses a single compile-time interface and does not
need access to the "internal" type(s) could be defined as:

auto DoSomething (static Range r) {...}

This would be lowered to:

auto DoSomething(R, T) (R r) if staticImplements!(R, Range!T) {...}


Multiple arguments
------------------

If the function needs to access several compile-time interfaces, or
if it needs access to the "internal" type(s), it could be defined as:

auto DoSomething(T, U) (static Range!T r1, static Range!U r2) {...}

This would be lowered to:

auto DoSomething(R1, T, R2, U) (R1 r1, R2 r2)
    if (staticImplements!(R1, Range!T) &&
        staticImplements!(R2, Range!U))
{...}


Specific internal data type
---------------------------

If the function requires a specific internal data type, it could be
defined as:

auto DoSomething (static Range!int r) {...}

This would be lowered to:

auto DoSomething(R) (R r) if staticImplements!(R, Range!int) {...}


staticImplements
----------------

Note that these lowerings use a "staticImplements" constraint. This
constraint checks that a class (or interface) implements all of the
methods defined in a static interface. It does not require that the
class inherit from the interface (ISTR that somebody already wrote
something similar for regular interfaces).


		Jerome
-- 
mailto:jeberger at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111128/80c99189/attachment.pgp>


More information about the Digitalmars-d mailing list