Well sorry to do this, chaps, but I think I'm coming to the conclusion that we need to borrow C#'s idea and require inout and out be explicit stated within the calling code. It's just too ambiguous otherwise. I'm working away on the reg stuff, and marking certain things out as appropriate, but then having to jump back and forth for the declarations.

The more I learn more new languages, the more I am surprised by just how much C did things right.

I think we need explicit inout/out or we need to get rid of out, and use pointers and the & operator. (Naturally, I don't want the former, so let me sell you the former).

Flame away ...

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkgkvd$2qv4$2@digitaldaemon.com...
> Well sorry to do this, chaps, but I think I'm coming to the conclusion
that
> we need to borrow C#'s idea and require inout and out be explicit stated within the calling code. It's just too ambiguous otherwise. I'm working
away
> on the reg stuff, and marking certain things out as appropriate, but then having to jump back and forth for the declarations.
>
> The more I learn more new languages, the more I am surprised by just how much C did things right.
>
> I think we need explicit inout/out or we need to get rid of out, and use pointers and the & operator. (Naturally, I don't want the former, so let
me
> sell you the former).
>
> Flame away ...

I don't understand. Can you post an example?

What, and back up my preposterous claims!? You're joking right? <G>

Let me find one that exemplifies what I mean ...

"Walter" <walter@digitalmars.com> wrote in message news:bkglkj$2t77$1@digitaldaemon.com...
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkgkvd$2qv4$2@digitaldaemon.com...
> > Well sorry to do this, chaps, but I think I'm coming to the conclusion
> that
> > we need to borrow C#'s idea and require inout and out be explicit stated within the calling code. It's just too ambiguous otherwise. I'm working
> away
> > on the reg stuff, and marking certain things out as appropriate, but
then
> > having to jump back and forth for the declarations.
> >
> > The more I learn more new languages, the more I am surprised by just how much C did things right.
> >
> > I think we need explicit inout/out or we need to get rid of out, and use pointers and the & operator. (Naturally, I don't want the former, so let
> me
> > sell you the former).
> >
> > Flame away ...
>
> I don't understand. Can you post an example?
>
>

Ok,

I've declared

    LONG RegQueryValueExA(in HKEY hkey, in LPCSTR lpValueName, in Reserved
reserved, out REG_VALUE_TYPE type, in void *lpData, inout DWORD cbData);

used as in

    private void Key_QueryValue(in HKEY hkey, in char[] name, out uint
value, out REG_VALUE_TYPE type)
    {
        //printf("Key_QueryValue(uint)\n");

        DWORD cbData = value.size;
        LONG res  = RegQueryValueExA(hkey, name, RESERVED, type, &value,
cbData);

        ...

cbData is inout, but it's impossible to tell that from looking at the definition of Key_QueryValue(). Of course, I could not have been "smart" in messing with the C signature of RegQueryValueExA(), but then I'd be using the & within the client code. Which pretty much makes my case, I think.

This is one of the (few ;=) )things I don't like about C++, but at least
there's const to comfort us ... arf arf.

Ok, am OTT OT, so off now.




"Walter" <walter@digitalmars.com> wrote in message news:bkglkj$2t77$1@digitaldaemon.com...
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkgkvd$2qv4$2@digitaldaemon.com...
> > Well sorry to do this, chaps, but I think I'm coming to the conclusion
> that
> > we need to borrow C#'s idea and require inout and out be explicit stated within the calling code. It's just too ambiguous otherwise. I'm working
> away
> > on the reg stuff, and marking certain things out as appropriate, but
then
> > having to jump back and forth for the declarations.
> >
> > The more I learn more new languages, the more I am surprised by just how much C did things right.
> >
> > I think we need explicit inout/out or we need to get rid of out, and use pointers and the & operator. (Naturally, I don't want the former, so let
> me
> > sell you the former).
> >
> > Flame away ...
>
> I don't understand. Can you post an example?
>
>

btw, no-one need point out my omission of toStringz(). I'm fixing all those
atm.

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkgmi1$2v24$1@digitaldaemon.com...
> Ok,
>
> I've declared
>
>     LONG RegQueryValueExA(in HKEY hkey, in LPCSTR lpValueName, in Reserved
> reserved, out REG_VALUE_TYPE type, in void *lpData, inout DWORD cbData);
>
> used as in
>
>     private void Key_QueryValue(in HKEY hkey, in char[] name, out uint
> value, out REG_VALUE_TYPE type)
>     {
>         //printf("Key_QueryValue(uint)\n");
>
>         DWORD cbData = value.size;
>         LONG res  = RegQueryValueExA(hkey, name, RESERVED, type, &value,
> cbData);
>
>         ...
>
> cbData is inout, but it's impossible to tell that from looking at the definition of Key_QueryValue(). Of course, I could not have been "smart"
in
> messing with the C signature of RegQueryValueExA(), but then I'd be using the & within the client code. Which pretty much makes my case, I think.
>
> This is one of the (few ;=) )things I don't like about C++, but at least
> there's const to comfort us ... arf arf.
>
> Ok, am OTT OT, so off now.
>
>
>
>
> "Walter" <walter@digitalmars.com> wrote in message news:bkglkj$2t77$1@digitaldaemon.com...
> >
> > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkgkvd$2qv4$2@digitaldaemon.com...
> > > Well sorry to do this, chaps, but I think I'm coming to the conclusion
> > that
> > > we need to borrow C#'s idea and require inout and out be explicit
stated
> > > within the calling code. It's just too ambiguous otherwise. I'm
working
> > away
> > > on the reg stuff, and marking certain things out as appropriate, but
> then
> > > having to jump back and forth for the declarations.
> > >
> > > The more I learn more new languages, the more I am surprised by just
how
> > > much C did things right.
> > >
> > > I think we need explicit inout/out or we need to get rid of out, and
use
> > > pointers and the & operator. (Naturally, I don't want the former, so
let
> > me
> > > sell you the former).
> > >
> > > Flame away ...
> >
> > I don't understand. Can you post an example?
> >
> >
>
>

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkgkvd$2qv4$2@digitaldaemon.com... <snip>
> The more I learn more new languages, the more I am surprised by just how much C did things right.
>
> I think we need explicit inout/out or we need to get rid of out, and use pointers and the & operator. (Naturally, I don't want the former, so let me

:) You must be joking! Pointers and pointer arithmetic are root of all
 evil. They give also a lot of arguments against const/readonly <G>
... and const/readonly are only a wimpy way to make our imperative
 language to behave more predictably like functional languages do ;)

Oh, I see what you mean. You're interfacing with C code that uses a pointer to simulate inout. The solution (as you suggested) is to NOT try to rewrite the C declaration into using inout, just go ahead and use the pointer method for it. Let's face it, when you're dealing with C code, you have to deal with C'isms like pointers and addresses. Otherwise, you're faced with things like trying to rewrite microsoft's enormous documentation database and all the established wisdom of how to call those API functions. We've all got better things to do <g>.

We had a similar discussion a while back about rewriting windows.d to use strong typedefs rather than aliases. It's a noble thought, but I think it is better for us to spend time writing cool new D class libraries than trying to reengineer microsoft's APIs.

As for inout parameters, calling

result=foo(x,&y);

(shouldn't) does not necessarily mean that &y is the pointer to y, simply it means that y is an inout parameter. And this will be visible also at the calling time, not only in the definition. Just an ideea.

Felix

In article <bkkrm2$v70$1@digitaldaemon.com>, Walter says...
>
>Oh, I see what you mean. You're interfacing with C code that uses a pointer to simulate inout. The solution (as you suggested) is to NOT try to rewrite the C declaration into using inout, just go ahead and use the pointer method for it. Let's face it, when you're dealing with C code, you have to deal with C'isms like pointers and addresses. Otherwise, you're faced with things like trying to rewrite microsoft's enormous documentation database and all the established wisdom of how to call those API functions. We've all got better things to do <g>.
>
>We had a similar discussion a while back about rewriting windows.d to use strong typedefs rather than aliases. It's a noble thought, but I think it is better for us to spend time writing cool new D class libraries than trying to reengineer microsoft's APIs.
>
>

> As for inout parameters, calling
>
> result=foo(x,&y);
>
> (shouldn't) does not necessarily mean that &y is the pointer to y, simply
it
> means that y is an inout parameter. And this will be visible also at the
calling
> time, not only in the definition. Just an ideea.
>
> Felix
>

In a language that does not even support const as a type modifier, this would not make much sense to have that clue... I think that const modifier is much more important... to makes safe program.

Also, I think it would be very easy to make an editor that would color
syntax in, inout and out parameters differently (for ex. in: italic, inout :
italic and bold, out: bold). Any any good editor should be able to
write you the prototype as you are written code.

I don't want to clutter my code with those & and if they are optional,¸ they would not always be used.

For me, using & is like hungarian notation... Although, it give us some hints, we should not uses it. These were tricks for C language in the 80's that are less relevant these days...

Anyway, since & already has the meaning of an address, it should be something else (maybe @) but I think that by default, we should not have to indicate it a calling site so I would opt for something that indicate parameters we want to ensure they are not modified.

A modern language should be able to allows an editor to give the programmer those hints while in program (and this will ensure that those as consistent).

If we want to prevent an object to be modified, we should have a way to make it const... We might have an operator or a predefined property for that:

#a    // const access to a
##a // read-only access to a
a    // read-write access to a

or

a.const
a.readonly
a.readwrite
...

And if a const modifier is used, the final access would be strictiest one (but we might have modifier that indicate that more access is required so that it won't compile instead of restrictive the access)

a.needs_readwrite    // compile only if a is non-const (and not read-only)


And speaking of things that we might be able to control is the fact that a reference can or cannot be null...