www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - User-defined "opIs"

reply "Meta" <jared771 gmail.com> writes:
The following code fails under DMD 2.065:

struct Test
{
     bool opBinary(string op: "is", T: typeof(null))(T val)
     {
         return false;
     }

     bool opBinaryRight(string op: "is", T: typeof(null))(T val)
     {
         return false;
     }
}

void main()
{
     auto t = Test();
     //Error: incompatible types for ((t) is (null)): 'Test' and 
'typeof(null)'
     //assert(t !is null);
     //assert(null !is t);
}

Is this supposed to work, and if not, should an enhancement be 
made to allow it? This is stopping std.typecons.Proxy from being 
a true proxy. See the following:

struct Test
{
	int* ptr;
	mixin Proxy!ptr;
	
	this(int* p)
	{
		ptr = p;
	}
}

auto i = new int;
assert(i !is null);
auto t = Test(i);
//Error: incompatible types for ((t) !is (null)): 'Test' and 
'typeof(null)'
//assert(t !is null);
Sep 24 2014
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 24 September 2014 at 22:48:36 UTC, Meta wrote:
 Is this supposed to work, and if not, should an enhancement be 
 made to allow it?
It is not supposed to work - the docs don't list is as overridable (http://dlang.org/expression.html look for "Identity expressions") - and I don't think it should work either. Consider: class A { opIs() } if(a is null) If that were rewritten into if(a.opIs(null))... and a were null, you'd have some trouble. Putting in an automatic null pre-check would start to complicate that is currently a simple operator.
Sep 24 2014
parent "Meta" <jared771 gmail.com> writes:
On Wednesday, 24 September 2014 at 23:08:26 UTC, Adam D. Ruppe 
wrote:
 On Wednesday, 24 September 2014 at 22:48:36 UTC, Meta wrote:
 Is this supposed to work, and if not, should an enhancement be 
 made to allow it?
It is not supposed to work - the docs don't list is as overridable (http://dlang.org/expression.html look for "Identity expressions") - and I don't think it should work either. Consider: class A { opIs() } if(a is null) If that were rewritten into if(a.opIs(null))... and a were null, you'd have some trouble. Putting in an automatic null pre-check would start to complicate that is currently a simple operator.
I'm thinking more for structs, which can't be null. The only other option right now is to use alias this, but that won't work in Proxy's case. For classes, I agree it's tricky... I know we're trying to *remove* things from Object, but what if we added: class Object { static bool opIs(T, U)(inout(T) a, inout(U) b) inout { //Some implementation } } And calls to is on an object get rewritten as: Object.opIs!(typeof(a), typeof(b))(a, b) So `if (a is null)` becomes `if (Object.opIs(a, null))` only when a is a class. When it's a struct, it would just be rewritten as `<struct name>.opIs!T(val)`.
Sep 24 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 22:48:35 +0000
Meta via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Is this supposed to work, and if not, should an enhancement be=20
 made to allow it?
i don't think that ER is needed. `is` is non-overloadable by design. making it overloadable will bring in the requrements for something like `is_which_is_not_overloadable`. which in turn will be asked to make overloadable, which will bring... ah, and so on. ;-) i see some little problems with Proxy here, though. well, Proxy is not ideal. ;-)
Sep 24 2014
prev sibling next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/24/14 6:48 PM, Meta wrote:
 The following code fails under DMD 2.065:

 struct Test
 {
      bool opBinary(string op: "is", T: typeof(null))(T val)
      {
          return false;
      }

      bool opBinaryRight(string op: "is", T: typeof(null))(T val)
      {
          return false;
      }
 }

 void main()
 {
      auto t = Test();
      //Error: incompatible types for ((t) is (null)): 'Test' and
 'typeof(null)'
      //assert(t !is null);
      //assert(null !is t);
 }

 Is this supposed to work, and if not, should an enhancement be made to
 allow it? This is stopping std.typecons.Proxy from being a true proxy.
 See the following:

 struct Test
 {
      int* ptr;
      mixin Proxy!ptr;

      this(int* p)
      {
          ptr = p;
      }
 }

 auto i = new int;
 assert(i !is null);
 auto t = Test(i);
 //Error: incompatible types for ((t) !is (null)): 'Test' and 'typeof(null)'
 //assert(t !is null);
You're looking at it the wrong way. 'is' is not overridable, and shouldn't be. But the type of null should be overridable (or you should be able to tell the compiler "this type can be compared with null"). I believe there has been discussion on this in the past, can't remember where it led. -Steve
Sep 25 2014
prev sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
I'm against overloading identity checking, too. Instead I
would propose to change its definition to make Proxy structs
work. The rules are currently:

  For class objects, identity is defined as the object
  references are for the same object. Null class objects can
  be compared with is. 

  For struct objects, identity is defined as the bits in the
  struct being identical. 

  For static and dynamic arrays, identity is defined as
  referring to the same array elements and the same number of
  elements. 

  For other operand types, identity is defined as being the
  same as equality. 

If we changed that to:

  A byte for byte comparison of both operands is performed.
  For reference types this is the reference itself.

Breakage is limited to current uses of "is" that clone the
behavior of "==", which a deprecation warning could catch.
And to comparisons of slices with static arrays. (You'd have
to write `dynamicArr is staticArr[]` then.)
This is all comprehensible since you need to be educated about
the difference between value types and reference types anyways.
What it breaks it makes good for by allowing these to compare
equal:

struct CrcProxy { ubyte[4] value; }

CrcProxy crc32a;
ubyte[4] crc32b;

assert (crc32a is crc32b); // Yes, it is byte identical.

If empowering structs to fully emulate built-in types is still
on the agenda it might be the way of least resistance.

-- 
Marco
Sep 27 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Saturday, 27 September 2014 at 11:38:51 UTC, Marco Leise wrote:
 I'm against overloading identity checking, too. Instead I
 would propose to change its definition to make Proxy structs
 work. The rules are currently:

   For class objects, identity is defined as the object
   references are for the same object. Null class objects can
   be compared with is.

   For struct objects, identity is defined as the bits in the
   struct being identical.

   For static and dynamic arrays, identity is defined as
   referring to the same array elements and the same number of
   elements.

   For other operand types, identity is defined as being the
   same as equality.

 If we changed that to:

   A byte for byte comparison of both operands is performed.
   For reference types this is the reference itself.
Maybe allow this only for types that somehow implicitly convert to each other, i.e. via alias this?
 Breakage is limited to current uses of "is" that clone the
 behavior of "==", which a deprecation warning could catch.
 And to comparisons of slices with static arrays. (You'd have
 to write `dynamicArr is staticArr[]` then.)
 This is all comprehensible since you need to be educated about
 the difference between value types and reference types anyways.
 What it breaks it makes good for by allowing these to compare
 equal:

 struct CrcProxy { ubyte[4] value; }

 CrcProxy crc32a;
 ubyte[4] crc32b;

 assert (crc32a is crc32b); // Yes, it is byte identical.

 If empowering structs to fully emulate built-in types is still
 on the agenda it might be the way of least resistance.
Sep 28 2014
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 28 Sep 2014 10:44:47 +0000
schrieb "Marc Sch=C3=BCtz" <schuetzm gmx.net>:

 On Saturday, 27 September 2014 at 11:38:51 UTC, Marco Leise wrote:
   A byte for byte comparison of both operands is performed.
   For reference types this is the reference itself.
=20 Maybe allow this only for types that somehow implicitly convert=20 to each other, i.e. via alias this?
That sounds like a messy rule set on top of the original when alias this does not represent all of the type. You have a size_t and a struct with a pointer that aliases itself to some size_t that can be retrieved through that pointer. The alias this will make it implicitly convert to size_t and the byte for byte comparison will happily compare two equally sized varibles (size_t and pointer). So how narrow would the rule have to be defined before it reads: If you compare with a struct that consists only of one member that the struct aliases itself with, a variable of the type of that member will be compared byte for byte with the struct. --=20 Marco
Sep 28 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Sunday, 28 September 2014 at 14:27:56 UTC, Marco Leise wrote:
 Am Sun, 28 Sep 2014 10:44:47 +0000
 schrieb "Marc Sch├╝tz" <schuetzm gmx.net>:

 On Saturday, 27 September 2014 at 11:38:51 UTC, Marco Leise 
 wrote:
   A byte for byte comparison of both operands is performed.
   For reference types this is the reference itself.
Maybe allow this only for types that somehow implicitly convert to each other, i.e. via alias this?
That sounds like a messy rule set on top of the original when alias this does not represent all of the type. You have a size_t and a struct with a pointer that aliases itself to some size_t that can be retrieved through that pointer. The alias this will make it implicitly convert to size_t and the byte for byte comparison will happily compare two equally sized varibles (size_t and pointer). So how narrow would the rule have to be defined before it reads: If you compare with a struct that consists only of one member that the struct aliases itself with, a variable of the type of that member will be compared byte for byte with the struct.
Yeah, it wasn't a good idea. Somehow it felt strange to throw all type safety out of the window, but on the other hand, bit-level comparison is the purpose of `is`, which isn't typesafe to begin with.
Sep 28 2014
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 28 Sep 2014 14:43:03 +0000
schrieb "Marc Sch=C3=BCtz" <schuetzm gmx.net>:

 Yeah, it wasn't a good idea. Somehow it felt strange to throw all=20
 type safety out of the window, but on the other hand, bit-level=20
 comparison is the purpose of `is`, which isn't typesafe to begin=20
 with.
I have the same feeling. No matter how we do it, one of the comparisons will always be left behind: 1a) identity of references with same referred type - objects with same reference and common inheritance branch - static arrays and the full slice over them - pointers of same type 1b) reference identity after implicit casts per language rules - void* with reference type - void[] with typed array 2) raw bit level equality (includes 1a) and parts of 1b)) - proxy struct with wrapped type - signed with unsigned types on the bit level 3a) logical / overridable equality for user defined types - comparison of uint.max with -1 results in false - safe type widening 1.0f with 1.0, -1 with -1L, char types - opEquals() 3b) 3a) with "C-style" equality for built-in types - equal after integer type promotion - equal after implicit cast One can define these from other perspectives, and the bit-wise struct comparison may be seen as a default opEquals (which I do here) or as a raw bit equality. "=3D=3D" is doing 3b). "is" comprises 1a), 1b) and 3b) as a fallback to be defined for all types. Defining "is" as 2) would remove the overlap for both operators in 3b), but loose type-safety in 1a+b) and disallow comparison of `void[] is ulong[]` since their lengths will differ even if they span the same memory area. With two operators we can capture any two subsets which sound logical on their own, but not all of the possible notions of identity and equality. And since people already wonder about "is" in D and "=3D=3D=3D" in JavaScript it is probably not a good idea to add even more comparison operators. So I conclude that we will have to live with that shortcoming. --=20 Marco
Sep 29 2014