May 16, 2017
On 16.05.2017 22:00, H. S. Teoh via Digitalmars-d wrote:
> On Tue, May 16, 2017 at 09:48:07PM +0200, Timon Gehr via Digitalmars-d wrote:
> [...]
>> I'm saying no to this:
>>
>> ...
>> {
>>
>> }{
>>
>> }
> It doesn't have to be formatted that way. For example:
>
> 	int foo()
> 	in { assert(blah); }
> 	{
> 		// not so bad after all
> 	}

IMO, this is just as bad. It's the same thing.

>>> (Not to mention the IMO very ugly syntax clash with
>>> do-loops, which will reduce code readability even more.)
>>> ...
>>
>> Do you think your new syntax is significantly more readable? (Just
>> curious.)
>
> It at least gets rid of the verbosity of the current syntax.  I don't
> claim it's necessarily *significantly* more readable, but I'd consider
> it to be one step closer.  Getting all the way there would be another
> topic, and a very long, protracted one, given our track record.

But still: If we are going to break all usages of contracts, then why not just fix the entire syntax at once? It just seems to be a much better option than making it worse.
May 16, 2017
On 5/16/17 3:43 PM, Timon Gehr wrote:
> On 16.05.2017 21:25, Steven Schveighoffer wrote:
>> I'm specifically asking if just removing the 'keyword-ness' of it is not
>> doable for some reason.
>
> It's easy to do technically. (The bad thing about option 1 is that it's
> the kind of thing that would probably not arise from an up-front
> language design and requires history to explain.)

It's easy to explain. It looks better than just nothing between the two sets of braces :)

-Steve

May 16, 2017
On Monday, 15 May 2017 at 02:02:42 UTC, Basile B. wrote:
>>
>> int fun(int a) {
>>   in assert(...);
>>   out(x) assert(...);
>>
>>   // do stuff
>> }
>
> It's nice, i like it but it cant work as simply. You're forgetting that interface member functions can have contracts. With this syntax interfaces member functions would always have a body BUT the current semantic is that interface member functions with bodies are final methods. Boom. Interfaces don't work anymore because there's no easy way to make the difference between an interface member function that's final and an interface member function that's not pre-implemented (so overridable) but has contracts.

I agree with your points, but it doesn't necessarily preclude adding in/out statements. My only qualm is that they would seem very similar to scope statements. Perhaps scope(in) and scope(out(x)) or something like that. Would not break any code to do it.
May 16, 2017
On Tuesday, 16 May 2017 at 21:39:19 UTC, jmh530 wrote:
>
> I agree with your points, but it doesn't necessarily preclude adding in/out statements. My only qualm is that they would seem very similar to scope statements. Perhaps scope(in) and scope(out(x)) or something like that. Would not break any code to do it.

I meant adding in/out statements without removing the in/out block functionality the way it is now.
May 17, 2017
On Tuesday, 16 May 2017 at 18:57:37 UTC, H. S. Teoh wrote:
> To me, it's actually worse, because now you have a visual conflation with do-loops.
>
> Overall, what I don't like about contract syntax is that it is so unbearably verbose. It's not just the in and out blocks and the (IMO redundant) marking of the function body; it's also the repeated 'assert's that occur in the in and out blocks.
>
> 	int foo(T, U)(T t, U u)
> 	if (sigContraints!T && sigConstraints!U)
> 	in
> 	{
> 		assert(t > 0 && u < 10);
> 	}
> 	out(val)
> 	{
> 		assert(val > 1 && val < 5);
> 	}
> 	body
> 	{
> 		// function body here
> 	}
>
> I understand this DIP is only to address the `body` part of this ugly verbosity, but imagine how much better it would be if we could write something like this instead:
>
> 	int foo(T, U)(T t, U u)
> 	if (sigConstraints!T && sigConstraints!U)
> 	in (t > 0 && u < 10)
> 	out(foo > 1 && foo < 5 )
> 	{
> 		// function body here
> 	}
>
> This is just tentative example syntax, of course.  We can argue over its fine points later, but the point is that the current syntax is far too verbose, and can easily be reduced to half the number of lines.  Merely changing `body` to `do` does nothing to address this, and seems to me to be just more useless churn, replacing one bit of verbosity with another bit of verbosity. (Not to mention the IMO very ugly syntax clash with do-loops, which will reduce code readability even more.)
>
>
> T

I think there are several issues at hand, and they need to be dealt with individually:

1. `body` is a very useful identifier. It would be nice to have it available.

2. Contract syntax is too verbose.

3. a. Some people think code looks better with a keyword, e.g. `body`, `do`, etc. distinguishing the function from the contracts.

3. b. Other people think that such a keyword is unnecessarily redundant and does not justify its own existence.

I think the thread will be more productive if the posters commit to answering just one of these issues, and reserve other issues for other threads. As the DIP in question is directly meant to address issue #1, it makes sense to try to solve that problem and only that problem here.
May 17, 2017
On Wednesday, 17 May 2017 at 01:01:29 UTC, MysticZach wrote:
> I think the thread will be more productive if the posters commit to answering just one of these issues

Agreed. Let's hope it's the topic that the DIP is actually addressing ;-)

May 16, 2017
On Wednesday, May 17, 2017 01:01:29 MysticZach via Digitalmars-d wrote:
> I think there are several issues at hand, and they need to be dealt with individually:
>
> 1. `body` is a very useful identifier. It would be nice to have it available.
>
> 2. Contract syntax is too verbose.
>
> 3. a. Some people think code looks better with a keyword, e.g. `body`, `do`, etc. distinguishing the function from the contracts.
>
> 3. b. Other people think that such a keyword is unnecessarily redundant and does not justify its own existence.
>
> I think the thread will be more productive if the posters commit to answering just one of these issues, and reserve other issues for other threads. As the DIP in question is directly meant to address issue #1, it makes sense to try to solve that problem and only that problem here.

The issues are not completely separate, because one of the suggestions of how to make the change with regards to body is to replace it with function. So, while we don't need to decide to completely overhaul the syntax for contracts, we do need to decide what we're going to do with the place where body is used now - be it remove the need for body entirely, make it a contextual keyword so that it's still used in contracts but is also usable as an identifier, or replace it with another keyword such as function or do.

- Jonathan M Davis

May 17, 2017
On Wednesday, 17 May 2017 at 01:01:29 UTC, MysticZach wrote:

>
> I think there are several issues at hand, and they need to be dealt with individually:
>
> 1. `body` is a very useful identifier. It would be nice to have it available.
>
> 2. Contract syntax is too verbose.
>
> 3. a. Some people think code looks better with a keyword, e.g. `body`, `do`, etc. distinguishing the function from the contracts.
>
> 3. b. Other people think that such a keyword is unnecessarily redundant and does not justify its own existence.
>
> I think the thread will be more productive if the posters commit to answering just one of these issues, and reserve other issues for other threads. As the DIP in question is directly meant to address issue #1, it makes sense to try to solve that problem and only that problem here.

Let me interject here that the primary issue we should be focused on in this thread is whether or not the status of `body` as a reserved keyword can be revoked and, if so, how to best go about it. Debates about the verbosity of contracts are peripherally related (courtesy of Option 3 in the DIP), but should not be the primary focus of the discussion here.

I would also like to remind everyone that the preliminary review of this DIP happened some time ago, and that's the place where free-for-all discussions are appropriate. The purpose of this thread is not to improve or modify the DIP, but to provide Walter and Andrei more food for thought when they consider if and how to implement the DIP.

With that in mind, I ask that we try to reduce the noise a bit by focusing on the key points of the DIP. As I see it, these are:

* Is it a good idea to remove body's status as a reserved keyword?

* If so, which option is best?
  1) Make it contextual
  2) Replace it with another keyword (`function` was suggested in the DIP, `do` in this thread).
  3) A three-stage process of removal: make it optional, then deprecate it, then remove it completely (meaning, no keyword, reserved or contextual, is required for the function body in a contract).

If you'd like to discuss peripheral issues in depth, I ask that you start another thread to do so. Feel free to post a link to the new thread in this one.

Thanks!



May 17, 2017
On Wednesday, 17 May 2017 at 08:03:13 UTC, Mike Parker wrote:
> * Is it a good idea to remove body's status as a reserved keyword?
>
> * If so, which option is best?
>   1) Make it contextual
>   2) Replace it with another keyword (`function` was suggested in the DIP, `do` in this thread).
>   3) A three-stage process of removal: make it optional, then deprecate it, then remove it completely (meaning, no keyword, reserved or contextual, is required for the function body in a contract).

Option 4) Keep `body`, but make it both contextual *and* optional. It becomes usable as an identifier, and those who think it's unnecessary are appeased. The downside is that different programmers will include it or not, based on arbitrary preferences.

May 17, 2017
On Wednesday, 17 May 2017 at 09:53:49 UTC, MysticZach wrote:
> On Wednesday, 17 May 2017 at 08:03:13 UTC, Mike Parker wrote:
>> * Is it a good idea to remove body's status as a reserved keyword?
>>
>> * If so, which option is best?
>>   1) Make it contextual
>>   2) Replace it with another keyword (`function` was suggested in the DIP, `do` in this thread).
>>   3) A three-stage process of removal: make it optional, then deprecate it, then remove it completely (meaning, no keyword, reserved or contextual, is required for the function body in a contract).
>
> Option 4) Keep `body`, but make it both contextual *and* optional. It becomes usable as an identifier, and those who think it's unnecessary are appeased. The downside is that different programmers will include it or not, based on arbitrary preferences.

The problem with this option is the IDEs. D syntax so far doesn't require parsing to highlight, i.e you have a token and you know what is it directly, and this without looking at the previous tokens (which is basically what parsing does, detect token patterns).