Rust updates

[Chad J]

On 07/11/2012 02:00 PM, David Piepgrass wrote:
>
> I am particularly a fan of structural typing. I don't know if Rust uses
> it but Opa and other functional languages often do. You see, there's a
> problem that pops up in .NET all the time, and probably the same problem
> exists in D.
>
> Any time two libraries want to use the same concept, but the concept is
> not in the standard library, they need to define it. For instance if
> there is no "Point" type in the standard library, but two unrelated
> libraries need points, they will both define their own (amazingly,
> Points are poorly thought out in .NET and tightly bound to GUI
> libraries, so people define their own in some cases):
>
> // JoesLibrary
> struct Point!T { T x, y; /* followed by some manipulation functions */ }
>
> // FunkyLibrary
> struct Point!T { T x, y; /* followed by other manipulation functions */ }
>
> Sadly, the two point types are not compatible with each other. A client
> that wants to use both libraries now has an interoperability problem
> when he wants to pass data between the.
>
> Even a client that uses only one of the library, let's call it
> "JoesLibrary" has to import Point from "JoesLibrary", even if its
> functionality is not quite what the client wants. It would be much nicer
> if the client could define his own Point struct that seamlessly
> interoperates with Joes'. In D this is currently impractical, but I
> would enjoy designing a way to make it work (before you point out that
> "what if x and y are in a different order in the two structs" and "it
> could be T X,Y in one and T x,y in the other", yes, I know, It's on my
> list of problems to cleverly solve)
>
> A similar problem exists with interfaces, where two unrelated libraries
> expose two similar classes with some common functions, but you can't
> cast them to a common type in D. This is a solved problem in Go
> (http://www.airs.com/blog/archives/277) and it's actually pretty easy
> for a compiler to magically cast a class to an interface that the class
> did not declare--if the underlying language is designed for that, anyway.
>
> In fact, in .NET at least, the same problem exists even if the libraries
> DO know about each other and are even written by the same person and use
> identical interfaces. The problem is, if I write two libraries A and B,
> and I want them to be interoperable, then I need to factor out the
> common structs and interfaces to a microscopic third library, I. But
> from the client's perspective, if a client only knows about A or B, he
> will think it's stupid that I require him to use and deploy two
> DLLs/so's (A and I, or B and I) instead of one. In D I guess it's not
> the same, though.
>

I'm pretty sure this interoperability thing is solved in D, at least at 
compile time.

Example:

import std.traits;

/// Returns true if T is a Point type.
template isPoint(T)
{
     enum bool isPoint = is(typeof(
     {
         T point;

         // (x,y) should be numeric.
         static assert ( isNumeric!(typeof(point.x)) );
         static assert ( isNumeric!(typeof(point.y)) );

         auto x = point.x; // x is readable
         point.x = x;      // x is writable

         auto y = point.y; // y is readable
         point.y = y;      // y is writable
     }));
}

struct MyPointType
{
     float x;
     float y;
}

struct AnotherPointType
{
     int x;
     int y;
}

struct NotAPoint
{
     char[] x;
     char[] y;
}

// TODO: are x and y allowed to have differing types?
static assert(isPoint!MyPointType);
static assert(isPoint!AnotherPointType);
static assert(!isPoint!NotAPoint);

auto myPointCalculation(P1,P2)( P1 p1, P2 p2 ) if ( isPoint!P1 && 
isPoint!P2 )
{
     p1.x += p2.x;
     p1.y += p2.y;
     return p1;
}

import std.stdio;
void main()
{
     MyPointType p1;
     AnotherPointType p2;
     p1.x = 3.5;
     p1.y = 5.0;
     p2.x = 2;
     p2.y = 2;
     writefln("(before) p1 == (%s, %s)",p1.x,p1.y);
     p1 = myPointCalculation(p1,p2);
     writefln("(after)  p1 == (%s, %s)",p1.x,p1.y);
}



At the command line:
chad at Hugin ~/dprojects/dtesting/points $ dmd points.d
chad at Hugin ~/dprojects/dtesting/points $ ./points
(before) p1 == (3.5, 5)
(after)  p1 == (5.5, 7)