www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Future of contract-based programming in D

reply "Delirius" <no spam.com> writes:
The D features which interest me the most are those supporting 
contract-based programming. I want to experiment with that and I 
know no other production ready  language which has this level of 
support, except the original gangsta Eiffel but the only 
supported Eiffel compiler is proprietary and expensive.

Thing is, while contract-based programming was promoted by Walter 
Bright in the early days it seems to get no attention nowadays. 
There are critical bugs in it e.g. contracts do not work 
correctly with interfaces. Also the compiler does not utilize the 
contracts for advanced static analysis and optimizations which 
are enabled by them.

But the most worrying thing is that Andrei Alexandrescu obviously 
does not like contract-based programming at all. I read a thread 
here where he wrote you should get rid of those in/out contracts 
and replace them with assert()s in the function body.

Now we all know that the vultures are already circling above Mr. 
Bright and after his departure Alexandrescu will be D's Ceausescu 
(horrible pun intended) and that really makes me worry about the 
future of contract-based programming in D.

But I am not following D's development that closely it is just 
one of many interesting languages I casually watch / consider for 
experiments. So I would like to hear a more inside view of the 
current and future state of contract-based programming in D.
Apr 07 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 7 April 2015 at 12:51:45 UTC, Delirius wrote:

 I know no other production ready  language which has this level 
 of support, except the original gangsta Eiffel but the only


Ada2012? Some languages use "require" and "ensure" or a similar 
notion in the body of  a function for pre/post conditions.

I have no idea where D contracts go, but the current in/out/body 
syntax is too noisy to be worth using IMO.
Apr 07 2015
parent "rumbu" <rumbu rumbu.ro> writes:
On Tuesday, 7 April 2015 at 13:11:01 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 7 April 2015 at 12:51:45 UTC, Delirius wrote:

 I know no other production ready  language which has this 
 level of support, except the original gangsta Eiffel but the 
 only


 Ada2012? Some languages use "require" and "ensure" or a similar 
 notion in the body of  a function for pre/post conditions.

 I have no idea where D contracts go, but the current 
 in/out/body syntax is too noisy to be worth using IMO.



https://msdn.microsoft.com/en-us/library/dd264808%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396

Personally, I think that the D contracts looks nicer, but they 
are not so versatile like an attribute solution.
Apr 07 2015
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 7 April 2015 at 12:51:45 UTC, Delirius wrote:

 The D features which interest me the most are those supporting 
 contract-based programming. I want to experiment with that and 
 I know no other production ready  language which has this level 
 of support, except the original gangsta Eiffel but the only 
 supported Eiffel compiler is proprietary and expensive.


EiffelStudio does have an open source license for non commercial 
purposes.

You are also forgetting Ada 2012, Spark, .NET, Clojure, Raket 
among many others.

C++17 also has a few proposals for contract programming (N4160, 
N1962, N4075, N4110).

--
Paulo
Apr 07 2015
prev sibling next sibling parent reply "w0rp" <devw0rp gmail.com> writes:
I'm a big fan of contracts, and for me it's one of the D features 
I love. The syntax really doesn't bother me. Given the rest of 
the syntax in the language, it's not possible to reduce it much 
further. Then again, I'm not one to care about syntax too much 
anyway. I tend to care more about semantics.

I think if you don't like contracts, they just take some getting 
used to. After you use them enough, you might find yourself 
writing contracts quite a lot. As far as bugs with contracts and 
classes go, I don't know. I don't write many classes or 
interfaces in D myself.
Apr 07 2015
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Apr 07, 2015 at 06:20:06PM +0000, w0rp via Digitalmars-d wrote:

 I'm a big fan of contracts, and for me it's one of the D features I
 love.  The syntax really doesn't bother me. Given the rest of the
 syntax in the language, it's not possible to reduce it much further.
 Then again, I'm not one to care about syntax too much anyway. I tend
 to care more about semantics.
 
 I think if you don't like contracts, they just take some getting used
 to.  After you use them enough, you might find yourself writing
 contracts quite a lot. As far as bugs with contracts and classes go, I
 don't know. I don't write many classes or interfaces in D myself.


D doesn't force anyone to use contracts, but they're there for people
who want/need to use them. I'm not a DbC person, but I do use D
contracts every now and then as a safety measure in my library code, to
prevent accidental regressions or API misuses.

The current DbC implementation is a little disappointing in some areas,
though, which limits their usefulness in serious DbC use cases. One
especially annoying one is the fact that contracts are compiled and
linked into the callee (library) rather than the caller (user code),
meaning that an optimized, release build of your library will not
contain contracts, whereas shipping the library with contracts means the
user can't turn them off even if they compile with -release.
Fortunately, I'm not a big DbC user so what D currently has is Good
Enough(tm) for me.


T

-- 
Life would be easier if I had the source code. -- YHL
Apr 07 2015
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
On Tuesday, 7 April 2015 at 12:51:45 UTC, Delirius wrote:

 I read a thread here where he wrote you should get rid of those 
 in/out contracts and replace them with assert()s in the 
 function body.


That was only because contracts with Allman style increase line 
count.

BTW, what do you think about this problem: 
http://forum.dlang.org/post/cokicokwqnscaktxifze forum.dlang.org ?
Apr 08 2015
next sibling parent reply "Pierre Krafft" <kpierre+dlang outlook.com> writes:
On Wednesday, 8 April 2015 at 11:26:38 UTC, Kagamin wrote:

 BTW, what do you think about this problem: 
 http://forum.dlang.org/post/cokicokwqnscaktxifze forum.dlang.org 
 ?


That's a great feature! Don't inherit if it's not the right tool, 
and it almost never is. We have interfaces and alias this with 
 disable so composition is really easy to do.
I am starting to think that when we have multiple alias this we 
would be better of if we stopped using inheritance at all. Except 
for the syntax I can't come up with a problem that would be 
better solved using inheritance than using composition.
Apr 08 2015
parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 8 April 2015 at 12:07:18 UTC, Pierre Krafft wrote:

 Except for the syntax I can't come up with a problem that would 
 be better solved using inheritance than using composition.


How would you interate a collection of widgets without 
polymorphism, i.e. any generic handling?
Apr 08 2015
parent reply "Pierre Krafft" <kpierre+dlang outlook.com> writes:
On Wednesday, 8 April 2015 at 12:13:00 UTC, Kagamin wrote:

 On Wednesday, 8 April 2015 at 12:07:18 UTC, Pierre Krafft wrote:

 Except for the syntax I can't come up with a problem that 
 would be better solved using inheritance than using 
 composition.


 How would you interate a collection of widgets without 
 polymorphism, i.e. any generic handling?


I mention the tool I use in the post.

 On Wednesday, 8 April 2015 at 12:07:18 UTC, Pierre Krafft wrote:
 We have interfaces and alias this with  disable so composition 
 is really easy to do.


So use a collection of interface instead of a collection of base 
class. If you squint you could say that what I promote is a way 
of doing inheritance, and I would agree. This is like doing 
inheritance, with a bit worse syntax but with greater flexibility.
Apr 08 2015
parent "Kagamin" <spam here.lot> writes:
On Wednesday, 8 April 2015 at 13:34:29 UTC, Pierre Krafft wrote:

 So use a collection of interface instead of a collection of 
 base class. If you squint you could say that what I promote is 
 a way of doing inheritance, and I would agree. This is like 
 doing inheritance, with a bit worse syntax but with greater 
 flexibility.


How can it improve DbC? No matter what implements interface, if 
it needs to strengthen its contract, it fails. Also composition 
is an implementation detail, abstracted by the interface, right? 
How is it relevant?
Apr 08 2015
prev sibling parent "Timon Gehr" <timon.gehr gmx.ch> writes:
On Wednesday, 8 April 2015 at 11:26:38 UTC, Kagamin wrote:

 On Tuesday, 7 April 2015 at 12:51:45 UTC, Delirius wrote:

 I read a thread here where he wrote you should get rid of 
 those in/out contracts and replace them with assert()s in the 
 function body.


 That was only because contracts with Allman style increase line 
 count.

 BTW, what do you think about this problem: 
 http://forum.dlang.org/post/cokicokwqnscaktxifze forum.dlang.org 
 ?


The usual way to resolve this would be to make (part of) the in 
contract a polymorphic function of the parent class.
Apr 08 2015
prev sibling parent reply "UselessManagerine" <hgfdhfdghh zerzer.ch> writes:
On Tuesday, 7 April 2015 at 12:51:45 UTC, Delirius wrote:

 The D features which interest me the most are those supporting 
 contract-based programming. I want to experiment with that and 
 I know no other production ready  language which has this level 
 of support, except the original gangsta Eiffel but the only 
 supported Eiffel compiler is proprietary and and expensive.


Doesn't a OSS version exist, in paralelle auf the commerzial one ?
Apr 08 2015
parent "Delirius" <no spam.com> writes:
On Wednesday, 8 April 2015 at 12:43:09 UTC, UselessManagerine 
wrote:

 Doesn't a OSS version exist, in paralelle auf the commerzial 
 one ?


In my book all those "GPL your code or buy an expensive 
enterprise license" offers well as might not exist. They are 
attractive to very few people. Also in the case of Ada at least 
the GPLed drop from AdaCore is a joke, it is completely 
unsupported, there is no community around it etc.


extensive support for DbC these days. Seems to be more advanced 
than what D has. I am a little disappointed that I could not get 
a statement from the D developers about where they plan to go 
with DbC in D but it is not really relevant for me anymore anyway.

Thanks everyone.
Apr 08 2015