• MysticZach (6/6) May 23 2017 I made a pull request for a new DIP dealing with contract syntax:
• arturg (12/19) May 23 2017 how about @uda based contracts?
• MysticZach (24/35) May 23 2017 Well I was going for three things:
• Timon Gehr (2/12) May 25 2017 For inspiration: https://github.com/Microsoft/dafny

MysticZach <reachzach ggmail.com> writes:

I made a pull request for a new DIP dealing with contract syntax:

https://github.com/dlang/DIPs/pull/66

I write the DIP in response to the discussions for DIP 1003: 
http://forum.dlang.org/thread/wcqebjzdjxldeywlxjcd forum.dlang.org

This DIP is not under any kind of formal review yet. I just 
wanted to let people know that it's there.

arturg <var.spool.mail700 gmail.com> writes:

On Tuesday, 23 May 2017 at 17:28:21 UTC, MysticZach wrote:
 I made a pull request for a new DIP dealing with contract 
 syntax:

 https://github.com/dlang/DIPs/pull/66

 I write the DIP in response to the discussions for DIP 1003: 
 http://forum.dlang.org/thread/wcqebjzdjxldeywlxjcd forum.dlang.org

 This DIP is not under any kind of formal review yet. I just 
 wanted to let people know that it's there.

how about  uda based contracts?

 in(x => x < 100)
 out((ret) { assert(ret > 0, "some text"); })
int fun(int i) { return someVal; }

they could also be used on type definitions,

 out((t) { assert(t); })
  class NotNull {}

or temporarly on instances

 in(t => t !is null) auto notNull = new NotNull;

you could also have  inout as a combination.
another feature would be that they could be introspected.

MysticZach <reachzach ggmail.com> writes:

On Tuesday, 23 May 2017 at 19:04:46 UTC, arturg wrote:
 how about  uda based contracts?

  in(x => x < 100)
  out((ret) { assert(ret > 0, "some text"); })
 int fun(int i) { return someVal; }

 they could also be used on type definitions,

  out((t) { assert(t); })
  class NotNull {}

 or temporarly on instances

  in(t => t !is null) auto notNull = new NotNull;

 you could also have  inout as a combination.
 another feature would be that they could be introspected.

Well I was going for three things:

1. contracts simple to write, with minimal "extra plumbing", i.e. 
without brackets and parentheses
2. utilize existing contract infrastructure
3. minimal divergence from existing syntax and semantics.

While not having to write `assert` in contracts would save a 
little space, it reduces what you can do with them, and also 
introduces a whole new semantics. The  uda contract system you 
suggest would require extensive description, documentation, and 
probably implementation effort. It would have to demonstrate that 
there was no better way to solve the problems it solves. (I'm not 
even sure I can justify my little syntax change, let alone a 
whole new semantics. I don't even know if contracts in general 
are important enough to be worth improving their syntax.)

So yeah, one could do things differently. But just because you 
_can_ do things differently doesn't mean you should. And 
justifying _why_ you should is not easy. And if people are being 
reasonable, they should maintain very high standards for what 
goes into a general-purpose programming language. Because there 
are a lot of things you can't take back once they're in there. 
(On the other hand, you don't want to stagnate, and not change 
_anything_, just for fear of making a mistake. One should strive 
for a balance.)

Timon Gehr <timon.gehr gmx.ch> writes:

On 23.05.2017 19:28, MysticZach wrote:
 I made a pull request for a new DIP dealing with contract syntax:
 
 https://github.com/dlang/DIPs/pull/66
 
 I write the DIP in response to the discussions for DIP 1003: 
 http://forum.dlang.org/thread/wcqebjzdjxldeywlxjcd forum.dlang.org
 
 This DIP is not under any kind of formal review yet. I just wanted to 
 let people know that it's there.
 

For inspiration: https://github.com/Microsoft/dafny