> D allows lots of stuff that Bertrand Meyer does not like. If you want to follow his coding principles, you are free to do so, but obviously D was not designed to force people using a certain style, but to allow them to express themselves in the way they want to.

I'd call it an idiom than you can use, but Eiffel does not force you into
using it,
its just good practice and so has nothing to do with Eiffel forcing you into
anything. However Eiffel does seem to be designed to be very coherent and
the libraries are not an exception. But make your own exceptions. Except for
libraries where you'd probably not want two versions, one for side-effecting
queries and one for side-effecting queries for terseness. ;) A D-like
compromise would be to build the side-effecting query on top of the
separated command and query.

> I like Bertrand Meyer's ideas, but I think that they are a bit idealistic and lead to extremely wordy programs in real life. Just consider a stack class that offeres a "pop" routine. According to Bertrand Meyer, "pop" would be illegal and you should split it up into "get_top" and "remove_top"...

One more call, one less bug? ;)

Bent Rasmussen wrote:

>> I like Bertrand Meyer's ideas, but I think that they are a bit idealistic and lead to extremely wordy programs in real life. Just consider a stack class that offeres a "pop" routine. According to Bertrand Meyer, "pop" would be illegal and you should split it up into "get_top" and "remove_top"...
> 
> One more call, one less bug? ;)

I don't believe, splitting "pop" into two calls would prevent any bugs. It would be just as likely that you forget one "remove_top" somewhere in the code.

Every experienced C/C++/D programmer knows that side-effects of functions have to be taken carefully. Looking back at a long time of programming, I don't think that bugs caused by unexpected side-effects ever were a major problem. Actually, looking at exapmles like the ++/-- operators, side-effects are planted so deep inside the philosophy of C/C++/D that you might have a hard time if you want to follow Bertram Meyer's concepts.

"Benedikt Meurer" <benedikt.meurer@unix-ag.uni-siegen.de> wrote in message news:c8pjgl$k6c$1@digitaldaemon.com...
> Walter wrote:
> > "James McComb" <alan@jamesmccomb.id.au> wrote in message news:c8ophn$2flh$1@digitaldaemon.com...
> >
> >>If functions that return void and functions that return non-void should be used for fundamentally different purposes, when would it be a good idea to have function template parameterized to sometimes return void and sometimes return non-void?
> >
> > My thoughts exactly. I know this feature was added to C++, but are there legitimate uses for it, or is it a misfeature, or a workaround for
another
> > bug in C++?
>
> No, it is an important point in the C++ language, cause without it, you'd
end
> up writing a lot of template specialisations for void. Imagine the
following
> very simple example:

I see its need for that example, but I don't see that the example does anything useful <g>. The trouble is, I'm not an expert at using templates, so I'd have to take your word for it.

Norbert Nemec wrote:

> I like Bertrand Meyer's ideas, but I think that they are a bit idealistic
> and lead to extremely wordy programs in real life.

I agree with you. In case you think I worship Betrand Meyer, here's the same idea expressed by C++ guru Herb Sutter:

<quote>
Incidentally, have you ever grumbled at the way the standard library containers' pop functions (e.g., list::pop_back, stack::pop, etc.) don't return the popped value? Well, here's one reason to do this: It avoids weakening exception safety.
</quote>

James McComb

Walter wrote:
> 
> My thoughts exactly. I know this feature was added to C++, but are there
> legitimate uses for it, or is it a misfeature, or a workaround for another
> bug in C++?

This comes up a lot when using the algorithms from the C++ standard library.  They all want to pass functions or function objects around to do stuff, and the return type is a part of the template parameterization:

template<typedef Ty>
struct accumulate :
public std::unary_function<void,Ty>
{
    void operator()( Ty const& val ) { total += val; }
    Ty total;
};

It's pretty common to not care about a return type for these functions, but because of the template design a dummy one often has to be provided just to get the code to compile (I commonly change the void to a bool).

So there are legitimate uses for it as a workaround for design aspects of the C++ standard library :)  I personally don't have much of an issue with "return void;" from a semantic standpoint.  It seems pretty clear, if a bit odd.

Sean

James McComb wrote:

> Norbert Nemec wrote:
> 
>> I like Bertrand Meyer's ideas, but I think that they are a bit idealistic and lead to extremely wordy programs in real life.
> 
> I agree with you. In case you think I worship Betrand Meyer, here's the same idea expressed by C++ guru Herb Sutter:
> 
> <quote>
> Incidentally, have you ever grumbled at the way the standard library
> containers' pop functions (e.g., list::pop_back, stack::pop, etc.) don't
> return the popped value? Well, here's one reason to do this: It avoids
> weakening exception safety.
> </quote>

Sorry, I have no idea what he means with "weakening exception safety". I realize now, that STL's "pop" really doesn't return a value. Guess, I have to reconsider my former statements. Anyhow, I really would like to understand the rationale behind it.

In article <c8qoat$27jv$1@digitaldaemon.com>, Walter says...
>>I see its need for that example, but I don't see that the example does
>anything useful <g>. The trouble is, I'm not an expert at using templates, so I'd have to take your word for it.

I've used templates a lot in C++. I haven't used them in D (yet) because I'm working on a specific project, which just happens not to need them.

But I can tell you that being allowed to return void is something that you definitely need in a lot of generic programming.

You need it so much, that, if you DON'T put it into the language, then people *will* make their own workarounds for it. For example - I might change something like:

>       void printNiceMessage()
>       {
>           printf("hello\n");
>       }

to:

>       bit printNiceMessage()
>       {
>           printf("hello\n");
>           return true;
>       }

just so that I can use it in templates. But this clutters the interface, and confuses people - sometimes they end up testing the return value, thinking false means "something went wrong", when in fact, it can never return false at all. It would be better to allow void as a return type.

Arcane Jill

If you pop and return the pop'd value in one notional operation, it is possible for the element to be removed from the container, but for an exception to throw in the copy constructor of the returned value - if of class type - which would result in the element being lost, both from the container and from client code. This is an artefact of C++'s return-by-value semantics, and is not an issue in D. (Unless one can do such things with structs, which is counter to my current understanding.)

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c8s7dn$18u0$2@digitaldaemon.com...
> James McComb wrote:
>
> > Norbert Nemec wrote:
> >
> >> I like Bertrand Meyer's ideas, but I think that they are a bit idealistic and lead to extremely wordy programs in real life.
> >
> > I agree with you. In case you think I worship Betrand Meyer, here's the same idea expressed by C++ guru Herb Sutter:
> >
> > <quote>
> > Incidentally, have you ever grumbled at the way the standard library
> > containers' pop functions (e.g., list::pop_back, stack::pop, etc.) don't
> > return the popped value? Well, here's one reason to do this: It avoids
> > weakening exception safety.
> > </quote>
>
> Sorry, I have no idea what he means with "weakening exception safety". I realize now, that STL's "pop" really doesn't return a value. Guess, I have to reconsider my former statements. Anyhow, I really would like to understand the rationale behind it.

"Benedikt Meurer" <benedikt.meurer@unix-ag.uni-siegen.de> wrote in message news:c8o52s$1j0l$1@digitaldaemon.com...
> Hello,
>
> Would it be possible to add support for void returns, as in
>
> void f1 () { ... }
> void f2 () { ...; return f1 (); }

I have to say I am surprised that this isn't possible in D. In my opinion one of the most important things in any language is that it is consistent.

So if it is possible to do:
int f1 () { ... }
int f2 () { ...; return f1 (); }

then this should be allowed also
void f1 () { ... }
void f2 () { ...; return f1 (); }

Function f2 is declared to return void(nothing) and the return type
of f1 is also void, so it just makes prefect sence to redirect
f1s void to f2s void.

> to D? This would be invaluably helpful in template programming. Else one
has
> to either make heavy use of mixins or write a lot of specialisations.
>
> (Looking at the code, it seems, that only dmd/statement.c has to be
modified
> to archive this goal).
>
> regards,
> Benedikt
>
> --
> NetBSD Operating system:                       http://www.NetBSD.org/ pkgsrc "Work in progress":                  http://pkgsrc-wip.sf.net/ XFce desktop environment:                        http://www.xfce.org/ German Unix-AG Association:                   http://www.unix-ag.org/ os-network:                                 http://www.os-network.de/
>
> OpenPGP Key: http://www.home.unix-ag.org/bmeurer/#gpg

In article <c8o52s$1j0l$1@digitaldaemon.com>, Benedikt Meurer says...
>
>Hello,
>
>Would it be possible to add support for void returns, as in
>
>void f1 () { ... }
>void f2 () { ...; return f1 (); }
>
>to D? This would be invaluably helpful in template programming. Else one has to either make heavy use of mixins or write a lot of specialisations.
>
>(Looking at the code, it seems, that only dmd/statement.c has to be modified to archive this goal).


This idea could be taken further.  Instead of just for return types, imagine something like this:

void[int] set_of_int;

Now, I have a set.  The object is a map (assoc. array) but a map with no
key is a set.  I would need some way to determine if an element is present of
course.

Another example:

template(Bar) {
struct Baz {
char[] name;
Foo value;
}
}

Now, Bar!(void).Baz yields:

struct Baz {
char[] name;
};

Baz x;
x.value = 5; // Do nothing statement.
5;           // An equivalent statement.

A statement like "x.value = 4" would simply disappear.

I'm not saying this is a good idea; I'll let others speculate.  Essentially all statements using the "void" object would just disappear.  This allows the creation of optional fields.  (But would it be useful? not sure.)

Kevin