www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - new contract syntax DIP

reply 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.
May 23
next sibling parent reply 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.
May 23
parent 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.)
May 23
prev sibling parent 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
May 25