DIP 1009--Improve Contract Usability--Preliminary Review Round 1

MysticZach via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 20 18:06:40 PDT 2017


On Tuesday, 20 June 2017 at 21:04:16 UTC, Steven Schveighoffer 
wrote:
> On 6/20/17 1:42 PM, H. S. Teoh via Digitalmars-d wrote:
>> Here's my counter-proposal: since the sig constraint line uses
>> parentheses (and yes, I deliberately planted a sig constraint 
>> above just
>> to make this point), why not go for syntactical symmetry? 
>> I.e., like
>> this:
>> 
>> 	int myFunc(Args...)(Args args)
>> 	if (Args.length > 2)
>> 	in (args[0] != 0)
>> 	in (args[1] > 1);	// one semicolon to end them all
>
> This is much much better. The verbosity of contracts isn't 
> really the brace, it's the asserts.

I think it's both, and I think the brace is the only thing that 
can be improved upon. How could you justify insisting that 
everyone use the built-in asserts for their contracts? If you 
can, then okay, and other avenues are worth exploring. Are there 
not, however, many reasons to want to use other types of 
contracts? That's the main reason I went with my design, because 
I thought it was going too far to imply `assert` when people 
might want or need to use other things.

> This also gives the compiler a better handle on what causes the 
> thing to fail (better error message).

I'm pretty sure that the reason asserts are so sparse in terms of 
error information is due to the fear of slowdown, were they to 
contain more information. This tradeoff would be present 
regardless of contract syntax.

> IMO, this whole proposal doesn't carry enough weight, either 
> your version or the DIP itself. I would not be in favor. 
> Current syntax is understandable, and not too verbose IMO.

That's a fair opinion. I wish I had a crystal ball to see how 
many more people would use contracts if this DIP were accepted. I 
imagine a lot of people will agree with you. I also know that 
some people don't [1].

http://forum.dlang.org/post/mailman.2288.1494811099.31550.digitalmars-d@puremagic.com



More information about the Digitalmars-d mailing list