"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.374.1207809416.2351.digitalmars-d@puremagic.com...
> On 10/04/2008, Lionello Lunesu <lionello@lunesu.remove.com> wrote:
>>
>> > Janice Caron Wrote:
>> >
>> > ...
>> >
>> > D already outlaws having code that isn't run.  I would prefer for code
>> > that does nothing to be considered an error.  Of course, with most functions
>> > being impure, that's tough to enforce.  With pure functions, it should be
>>  >easy.
>
> No I did not. That was Jason House. Please be careful with your level
> of nesting!

Uh, the "..." part contains what you've said, not what follows it, so the quote was right (at least it looks just fine in my reader).

L. 

"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.375.1207810102.2351.digitalmars-d@puremagic.com...
> On 10/04/2008, Lionello Lunesu <lionello@lunesu.remove.com> wrote:
>>  Why? If pure-ness (uh, purity?) can be checked, it can also be deducted
>
> "purity" is the right word. (But "deducted" should be "deduced" :-))

:-) thanks.

>> (*), so the compiler could optimize/complain in either case.
>
> It would slow down compilation no end though. For example, a pure
> function is not allowed to call non-pure functions. Without the "pure"
> keyword, you'd have to follow through every function call recursively,
> and that could take a long time.

Yeah, but you'll have to visit those functions anyway, because you're compiling. Granted, header files should explicitely mention pure/notpure, and to make it safe, it must be mangled.

> Moreover, just because the compiler decides the function is impure,
> that doesn't necessarily mean that the programmer /intended/ for it to
> be impure. Perhaps there was a bug? Perhaps there was a silly, simple,
> one line bug, that the programmer could fix in a jiffy if the compiler
> would only say "Error: Line 53: Pure function cannot do XYZ"? It is
> far better for the programmer to document their intentions, so that
> the compiler can check that those intentions are actually met.

Good point.

L. 

Lionello Lunesu wrote:
> 
> "Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.375.1207810102.2351.digitalmars-d@puremagic.com...
>> On 10/04/2008, Lionello Lunesu <lionello@lunesu.remove.com> wrote:
>>>  Why? If pure-ness (uh, purity?) can be checked, it can also be deducted
>>
>> "purity" is the right word. (But "deducted" should be "deduced" :-))
> 
> :-) thanks.
> 
>>> (*), so the compiler could optimize/complain in either case.
>>
>> It would slow down compilation no end though. For example, a pure
>> function is not allowed to call non-pure functions. Without the "pure"
>> keyword, you'd have to follow through every function call recursively,
>> and that could take a long time.
> 
> Yeah, but you'll have to visit those functions anyway, because you're compiling. Granted, header files should explicitely mention pure/notpure, and to make it safe, it must be mangled.

Visited? Yes.
Look at their body? Not if they're in a different module, AFAICT.
If the function is in another module then the declaration should be enough (the fact that .di "headers" work confirms this), and the body can effectively be ignored beyond checking syntactical correctness (i.e. checking that it *could* be valid code provided all identifiers it uses resolve to stuff of appropriate types, but not actually looking up any of the identifiers mentioned in it).

On Thu, 10 Apr 2008 01:07:51 +0200, Janice Caron <caron800@googlemail.com> wrote:

> On 09/04/2008, Simen Kjaeraas <simen.kjaras@gmail.com> wrote:
>>  class foo
>>  {
>>         invariant int bar;
>>
>>         this()
>>         {
>>                 bar = 4;
>>         }
>>  }
>>
>>  This works under DMD 2.012.
>
> That's interesting. I did not know that.


I can't quite see what would be the difference between const and
invariant in this example.  It's a member variable that is local
to each instance, and cannot be changed. Why should it not work?

-- Simen

Lionello Lunesu wrote:
> 
> "Jason House" <jason.james.house@gmail.com> wrote in message news:ftiuj8$mob$1@digitalmars.com...
> 
>> Georg Wrede Wrote:
>>> Simen Kjaeraas wrote:
>>> > On Wed, 09 Apr 2008 15:40:37 +0200, Janice Caron wrote:
>>>
>>> >> You know that. I know that. Why would anyone think it strange?
>>> >
>>> > I think it is because invMemberFunc is invariant. Many read this as
>>> > "will not change anything", even though it is not what it means.
>>>
>>> I seriously think the problem is with the phrase "invMemberFunc is
>>> invariant".
>>>
>>> This leads people to think invariantness is a property of the function,
>>> instead of it merely requiring an invariant "this".
>>>
>>> Maybe we should figure out another way of stating it.
>>
>> Is that really the best solution?  Why not have do what people nievely think it does?  The code optimizer would benefit from that as well.
> 
> I agree.. And one less keyword, which, it seems, is a goal in itself.

I wasn't thinking of changing D, I was thinking more what we should *say* when we talk about invariantness and functions.

The phrase "f is invariant" really does not say that it wants something "invariant". In English it says that "there is a property invariantness, that f is". It's like saying somebody is Chinese. That is not the same as saying she wants Chinese food.

Any newcomer to this NG who doesn't have an extensive cultural background in C-like languages, will have a hard time before he realises that "f is invariant" actually only means "f loves an invariant 'this'".

Georg Wrede Wrote:

> Lionello Lunesu wrote:
> > 
> > "Jason House" <jason.james.house@gmail.com> wrote in message news:ftiuj8$mob$1@digitalmars.com...
> > 
> >> Georg Wrede Wrote:
> >>> Simen Kjaeraas wrote:
> >>> > On Wed, 09 Apr 2008 15:40:37 +0200, Janice Caron wrote:
> >>>
> >>> >> You know that. I know that. Why would anyone think it strange?
> >>> >
> >>> > I think it is because invMemberFunc is invariant. Many read this as "will not change anything", even though it is not what it means.
> >>>
> >>> I seriously think the problem is with the phrase "invMemberFunc is invariant".
> >>>
> >>> This leads people to think invariantness is a property of the function, instead of it merely requiring an invariant "this".
> >>>
> >>> Maybe we should figure out another way of stating it.
> >>
> >> Is that really the best solution?  Why not have do what people nievely think it does?  The code optimizer would benefit from that as well.
> > 
> > I agree.. And one less keyword, which, it seems, is a goal in itself.
> 
> I wasn't thinking of changing D,

Right, but I am ;)


> I was thinking more what we should *say* when we talk about invariantness and functions.

If we have to say special qualifiers every time we talk about stuff, it's a broken definition :(  The less corner cases there are, the easier it'll be to discuss, the easier it'll be to learn, and the lower the potential for compiler bugs will be...