In D, it will be an error to have any assert() expression have side effects. It is not practical for the compiler/runtime to guarantee to diagnose 100% of the side effects, but they'll be expected to catch the obvious ones like:

    assert(++i);

Russ Lewis wrote in message <3BCA687C.79AAC16B@deming-os.org>...
>I would add (f): you put functional code in an assert.  From time to time
I've made
>the critical mistake of trying to directly check the return code from a
function:
>
>assert(ImportantFunction(...) == true)
>
>At least in my compiler, when I compiled the Release version, the function
was never
>called.  Oops.
>
>--
>The Villagers are Online! http://villagersonline.com
>
>.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
>.[ (a version.of(English).(precise.more)) is(possible) ]
>?[ you want.to(help(develop(it))) ]
>
>

Walter wrote:

> In D, it will be an error to have any assert() expression have side effects. It is not practical for the compiler/runtime to guarantee to diagnose 100% of the side effects, but they'll be expected to catch the obvious ones like:
>
>     assert(++i);

This almost makes me think that you should be able to declare certain functions to have no side effects.  A little like you can declare member functions in C++ to be 'const', but applying to side effects.

Obviously, this wouldn't work for any linkages outside of the language...what would be the upsides and downsides of having this in the language for internal functions?  Would it be a noticable increase in compiler complexity?  Would it help optimization any?

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

In article <3BCDA7EC.3FEBB32B@deming-os.org>, "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote:

> Walter wrote:
> 
>> In D, it will be an error to have any assert() expression have side effects. It is not practical for the compiler/runtime to guarantee to diagnose 100% of the side effects, but they'll be expected to catch the obvious ones like:
>>
>>     assert(++i);
> 
> This almost makes me think that you should be able to declare certain functions to have no side effects.  A little like you can declare member functions in C++ to be 'const', but applying to side effects.

Yes, I agree with this idea, and was considering suggesting the same thing.  This would be useful as a guide to programmers to show that the function doesn't have any effect.

gcc has an extension attribute "const" which does just this (plus the function doesn't examine any other values, apparently).

(gcc also has a "noreturn" attribute which means that the function doesn't
return control to the caller.  This might also be useful.)

> Obviously, this wouldn't work for any linkages outside of the language...what would be the upsides and downsides of having this in the language for internal functions?  Would it be a noticable increase in compiler complexity?  Would it help optimization any?

Apparently it can be used in common subexpression elimination and loop optimisation.

Presumably the compiler could work this out itself?  In that case, the programmer doesn't have to worry about getting it wrong, and the result of the test for this can be stored in the symbol table for the module.


By the way, could the set of exported interfaces be produced (by some
utility) from the symbol table in a compiled module in readable form?
(Something like a .h file.)

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BCDA7EC.3FEBB32B@deming-os.org...
> Walter wrote:
>
> > In D, it will be an error to have any assert() expression have side
effects.
> > It is not practical for the compiler/runtime to guarantee to diagnose
100%
> > of the side effects, but they'll be expected to catch the obvious ones
like:
> >
> >     assert(++i);
>
> This almost makes me think that you should be able to declare certain
functions
> to have no side effects.  A little like you can declare member functions
in C++
> to be 'const', but applying to side effects.
>
> Obviously, this wouldn't work for any linkages outside of the
language...what
> would be the upsides and downsides of having this in the language for
internal
> functions?  Would it be a noticable increase in compiler complexity?
Would it
> help optimization any?

I'd rather try and have the compiler figure out if a function has side effects or not - it will be more reliable. The compiler already can reliably figure out if it is "noreturn".

> This almost makes me think that you should be able to declare certain
> functions
> to have no side effects.  A little like you can declare member functions
> in C++ to be 'const', but applying to side effects.

Look at the gcc manual: Section 5. Extensions to the C Language Family attribute 'const' for functions:
-----------------------------------------
const Many functions do not examine any values except their arguments, and have no effects except the return value. Basically this is just slightly more strict class than the pure attribute above, since function is not allowed to read global memory.

  Note that a function that has pointer arguments and examines the data
pointed to must not be declared const. Likewise, a function that calls a
non-const function usually must not be const. It does not make sense for a
const function to return void.

 The attribute const is not implemented in GCC versions earlier than 2.5.
An alternative way to declare that a function has no side effects, which
works in the current version and in some older versions, is as follows:
-----------------------------------------

> I'd rather try and have the compiler figure out if a function has side effects or not - it will be more reliable. The compiler already can reliably figure out if it is "noreturn".

But in the view of "programming by contract" paradigm, should the programmer be allowed to write the contract : "I will not depend or alter any global variables." ?

- Axel
-- 
|D) http://www.dtone.org

That's might be a good idea.

Axel Kittenberger wrote in message <9qlrq6$1l62$2@digitaldaemon.com>...
> I'd rather try and have the compiler figure out if a function has side effects or not - it will be more reliable. The compiler already can reliably figure out if it is "noreturn".

But in the view of "programming by contract" paradigm, should the programmer be allowed to write the contract : "I will not depend or alter any global variables." ?

- Axel
--
|D) http://www.dtone.org

THANK YOU!!!  <smooooch>

You've just knocked out the entire (f) class of bugs for D programmers!  ;)
Ok maybe 99% of the (f) bugs.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:9qj3h5$2ml$3@digitaldaemon.com...
> In D, it will be an error to have any assert() expression have side
effects.
> It is not practical for the compiler/runtime to guarantee to diagnose 100% of the side effects, but they'll be expected to catch the obvious ones
like:
>
>     assert(++i);

In article <9qophg$bku$1@digitaldaemon.com>, "Sean L. Palmer" <spalmer@iname.com> wrote:

> THANK YOU!!!  <smooooch>
> 
> You've just knocked out the entire (f) class of bugs for D programmers!
> ;) Ok maybe 99% of the (f) bugs.
> 
> Sean
> 
> "Walter" <walter@digitalmars.com> wrote in message news:9qj3h5$2ml$3@digitaldaemon.com...
>> In D, it will be an error to have any assert() expression have side
> effects.
>> It is not practical for the compiler/runtime to guarantee to diagnose 100% of the side effects, but they'll be expected to catch the obvious ones
> like:
>>
>>     assert(++i);


Why stop as assert?  Why not have a modifier for function parameters which says that whenever the function is called, the expression used to generate that parameter can't have side-effects.  This would be useful for writing your own assert handler, and perhaps other issues such as thread safety and order of expression evaluation.

For example:

 int x = 4;

 int modify_var() { x++;  return x; }

 void use_var(in no_effect my_int) {
    printf("%d\n", x + v);
 }

 use_var(4);   /* these are allowed */
 use_var(x);
 use_var(get_current_time_in_seconds());

 use_var(x++);  /* these are not allowed */
 use_var(modify_var());

> Why stop as assert?  Why not have a modifier for function parameters which says that whenever the function is called, the expression used to generate that parameter can't have side-effects.  This would be useful for writing your own assert handler, and perhaps other issues such as thread safety and order of expression evaluation.

Why stop even here? Why not make a language that does not allow any stupid side effects at all :)))))

=> ending up into the java-pascal line again? :o)

- Axel