http://d.puremagic.com/issues/show_bug.cgi?id=6857


David Piepgrass <qwertie256@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qwertie256@gmail.com


--- Comment #70 from David Piepgrass <qwertie256@gmail.com> 2012-07-08 14:27:53 PDT ---
I must say, I would be entirely opposed to fixing this "bug". As far as I can see, the arguments of Timon and deadalnix have been entirely theoretical, whereas it's not that hard to envision a situation where the user would fully desire and expect the wider contract of B to apply even though the static type is A.

Suppose that D did check *only* A's contract when calling into an A (that might be a B). I bet that if contracts were widely and exactingly used, cases where this causes trouble would pop up frequently. The main problem, I think, are low-level "deputies" that provide functionality for higher-level clients.

For example, consider a collection that only allows items that match certain constraints, but the constraints are eliminated in B:

// BTW I wanted to use an interface here, but I get
// "missing body { ... } after in or out"
// and then if I add a body, D complains that it is not abstract!
class A {
    abstract void add(Item item)
        in { assert(item.x > 0); } body {}
}
class B : A {
    override void add(Item item) in {} body {}
}
struct Item { int x; }

Now suppose I write a function that helpfully adds a series of items to an A:

void addAll(A set, Item[] arr...) {
    foreach(Item x; arr)
        set.add(x);
}

Finally, a client creates a B and tries to add some items to it. That should be okay, since B has no restrictions on the items:

B b = new B();
b.addAll(Item(-1), Item(-2), Item(-3));

Very few developers would consider this code to be in error. And if there is an error, where is it?

P.S. Besides which, the implementation difficulties mentioned by Walter in comment 58 are really big difficulties, that don't seem worth it for what appears to be a minor behavior tweak.

P.P.S. in http://dlang.org/function.html, surely the syntax described in "D-style Variadic Functions" is not the preferred technique since it isn't even mentioned in TDPL book. Ergo, the "Typesafe Variadic Functions" section should be first, and one of the two sections should explain to us why there are two entirely different syntaxes!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #71 from deadalnix <deadalnix@gmail.com> 2012-07-08 14:50:57 PDT ---
The error is in the fact that addAll isn't aware of B.

You can solve that easily with metaprograming, or by overloading addAll for B.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #72 from timon.gehr@gmx.ch 2012-07-08 14:58:07 PDT ---
(In reply to comment #70)
> I must say, I would be entirely opposed to fixing this "bug". As far as I can see, the arguments of Timon and deadalnix have been entirely theoretical,

It is irrelevant who made the arguments.

> whereas it's not that hard to envision a situation where the user would fully desire and expect the wider contract of B to apply even though the static type is A.
> 
> Suppose that D did check *only* A's contract when calling into an A (that might be a B). I bet that if contracts were widely and exactingly used, cases where this causes trouble would pop up frequently. The main problem, I think, are low-level "deputies" that provide functionality for higher-level clients.
> 
> For example, consider a collection that only allows items that match certain constraints, but the constraints are eliminated in B:
> 
> // BTW I wanted to use an interface here, but I get
> // "missing body { ... } after in or out"
> // and then if I add a body, D complains that it is not abstract!

Yah, that's a long standing bug.

> class A {
>     abstract void add(Item item)
>         in { assert(item.x > 0); } body {}
> }
> class B : A {
>     override void add(Item item) in {} body {}
> }
> struct Item { int x; }
> 
> Now suppose I write a function that helpfully adds a series of items to an A:
> 
> void addAll(A set, Item[] arr...) {
>     foreach(Item x; arr)
>         set.add(x);
> }
> 

This function is clearly in error. You could do it like this:

class A {
    abstract void add(Item item) in { assert(validate(item)); }
    bool validate(Item item) const pure { return item.x > 0; }
}

class B : A {
    override void add(Item item) {}
    override bool validate(Item item) const pure { return true; }
}

void addAll(A set, Item[] arr...)in{
    foreach(x; arr) assert(set.validate(x));
}body{
    foreach(x; arr) set.add(x);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #73 from timon.gehr@gmx.ch 2012-07-08 15:08:47 PDT ---
(In reply to comment #70)
> 
> P.S. Besides which, the implementation difficulties mentioned by Walter in comment 58 are really big difficulties, that don't seem worth it for what appears to be a minor behavior tweak.
> 

The reason why it is harder to implement is that it is more general.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #74 from Stewart Gordon <smjg@iname.com> 2012-07-08 15:59:47 PDT ---
(In reply to comment #72)
> (In reply to comment #70)
>> // BTW I wanted to use an interface here, but I get
>> // "missing body { ... } after in or out"
>> // and then if I add a body, D complains that it is not abstract!
> 
> Yah, that's a long standing bug.

See issue 6549.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #75 from David Piepgrass <qwertie256@gmail.com> 2012-07-08 17:05:28 PDT ---
> > I must say, I would be entirely opposed to fixing this "bug". As far as I can see, the arguments of Timon and deadalnix have been entirely theoretical,
> 
> It is irrelevant who made the arguments.

Relax, I didn't claim that it was relevant. Merely mentioning someone's name does not qualify as an ad-hominim attack.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #76 from yebblies <yebblies@gmail.com> 2012-07-10 02:54:06 EST ---
(In reply to comment #55)
> 
> Unfortunately, I do not currently see a reasonable way of implementing this. Fortunately, as is it does not inhibit correct programs, it only accepts some invalid ones.

I can't see any way to do it without changing the abi for virtual functions
with contracts.
But, if changing the abi was ok, I think something like this would work:

class A
{
   void func(..., __in_contract_ptr)
   {
      void __nested_in_contract_A_func() { ... }
      auto __in_contract = &__nested_in_contract_A_func;
      __in_contract.ptr = ptr;
      __in_contract();
      ...
   }
}

class B : A
{
   void func(..., __in_contract_ptr)
   {
      void __nested_in_contract_B_func() { ... }
      auto __in_contract = &__nested_in_contract_B_func;
      __in_contract.ptr = ptr;
      __in_contract();
      ...
   }
}

void main()
{
   B b = new B();
   b.func(..., &__nested_in_contract_B_func.ptr);
   A a = b;
   a.func(..., &__nested_in_contract_A_func.ptr);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #77 from Stewart Gordon <smjg@iname.com> 2012-07-09 11:12:52 PDT ---
(In reply to comment #76)
> I can't see any way to do it without changing the abi for virtual functions with contracts.

What about my suggestion of comment 61?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies@gmail.com


--- Comment #78 from yebblies <yebblies@gmail.com> 2012-07-10 04:43:07 EST ---
(In reply to comment #77)
> (In reply to comment #76)
> > I can't see any way to do it without changing the abi for virtual functions with contracts.
> 
> What about my suggestion of comment 61?

As Walter said, that requires argument forwarding, which introduces copying problems and doesn't work with variadics.  The precondition needs to be evaluated in the context of the function.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #79 from Stewart Gordon <smjg@iname.com> 2012-07-09 15:22:23 PDT ---
(In reply to comment #78)
> As Walter said, that requires argument forwarding, which introduces copying problems and doesn't work with variadics.

I thought I'd debunked that, but you're right.  By my proposal, user code would be calling either foo_dbc or foo depending on whether it's compiled in dev or release mode.  And foo_dbc forwards to foo.

But it does seem to be down to two problems with D's design:
- structs aren't guaranteed to be safe to just bit-copy (this problem was
introduced in D2)
- we have variadics that are really just C's variadics with typeinfo added

Something else I should've realised earlier: Why do D class methods need to be directly callable from C?  (How does C code hold a reference to a D object, anyway?)  Indeed, is even C++ designed to accommodate this?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------