request switch statement with common block

[luminousone]

On Monday, 5 August 2013 at 20:45:47 UTC, Borislav Kosharov wrote:
> On Monday, 5 August 2013 at 19:58:21 UTC, ron wrote:
>> On Monday, 5 August 2013 at 08:46:54 UTC, Andre Artus wrote:
>>> On Monday, 5 August 2013 at 06:28:12 UTC, luminousone wrote:
>>>> perhaps a more generic solution should be looked at, extend 
>>>> contracts to work with all scope blocks.
>>>>
>>>> switch(somenumber)
>>>> in {
>>>>  ... before stuff ...
>>>> }
>>>> out {
>>>>  .... after stuff ...
>>>> }
>>>> body {
>>>>  case 1:
>>>>  in {
>>>>     ... etc ....
>>>>  }
>>>>  out {
>>>>     ... more etc ...
>>>>  }
>>>>  body {
>>>>     ...
>>>>  }
>>>>  case 2:
>>>>    // and so on
>>>> }
>>>>
>>>> or perhaps
>>>>
>>>> for( int i = 0 ; i < 10 ; i ++ )
>>>> in {
>>>>  assert( i == 0 );
>>>> }
>>>> out {
>>>>  assert( i == 9 );
>>>> }
>>>> body {
>>>> ... stuff ...
>>>> }
>>>>
>>>> if it is desired for a particular contract block to be 
>>>> called in release builds perhaps a attribute label to mark 
>>>> it as a runtime block or something similar.
>>>>
>>>> foreach( i, k ; somerange )
>>>> @runtime in {
>>>> ...
>>>> }
>>>> body {
>>>> }
>>>
>>> Please do not take offense, but I do not see this as a good 
>>> idea. Contracts have a very different function; not just in 
>>> D, but every language that uses them. The idea is to support 
>>> design-by-contract programming. Overloading the constructs 
>>> for the purposes proposed here would, in my opinion, cause 
>>> confusion and/or weaken the proper use of contract 
>>> programming.
>>>
>>>
>>> The code in the contract conditions should never do anything 
>>> more than what is necessary to specify the contract. It 
>>> should not do explicit IO (other than implied by assert()), 
>>> mutate state, or anything like that.
>>>
>>> At the bottom of this page you can find a reading list for 
>>> more info.
>>> http://www.digitalmars.com/d/dbc.html
>>>
>>> Or for a general overview:
>>> http://en.wikipedia.org/wiki/Design_by_contract
>>>
>>> Walter, does the D compiler or any of it's companion tools do 
>>> any static analysis on the contracts? Such as a void 
>>> safety/null reference check?
>>
>> None taken, =-p.
>>
>> I don't see how this is different from current contract usage, 
>> right now they apply to function scopes only. currently I 
>> believe you could get a similar effect via using an inner 
>> function.
>>
>> void a() {
>>   int i = 0;
>>   void b()
>>   in {
>>      assert( i == 0 );
>>   }
>>   out {
>>      assert( i == 10 );
>>   }
>>   body {
>>      for( ; i < 10 ; i ++ ) {
>>         ... do something ...
>>      }
>>   }
>>   b();
>> }
>
> Speaking of contracts, and reading the docs I see:
> "Pre and Post Contracts
>
> The pre contracts specify the preconditions before a statement 
> is executed. The most typical use of this would be in 
> validating the parameters to a function. The post contracts 
> validate the result of the statement. The most typical use of 
> this would be in validating the return value of a function and 
> of any side effects it has..."
>
> So are contracts possible outside function declarations? For 
> example just scopes or random places in code.

I being zero is the precondition for that loop, and i being 10 is 
the post condition for that loop.

Pretty much I think that any scope can potentially fit the 
definition for contracts.

Really any block of code, can be considered to have pre and post 
conditions, functions just happen to be one way to organize code.