In article <dt55qh$bq0$1@digitaldaemon.com>, S. Chancellor says...
>
>In article <op.s44i7ehj6b8z09@ginger.vic.bigpond.net.au>, Derek Parnell says...
>>
>>The original poster, I think, was just saying it would be useful to have another option available for those things that are currently passed by value, and that option being that we can specify that instead of being passed by value that we want it to be passed by reference *and* that we don't want to use pointer notation to do that.
>
>Being the original poster, I can say this is almost exactly what I meant! At least someone understands what I was talking about!
>
>Also, I was stating not only that we don't want to use pointers, but we also don't want to use inout, because inout means we're going to change the value.
>
>-S.
>

That's what I understood it as, and why I suggested 'byref' as a replacement.

From your follow-up, I think the main problem you had with just 'byref' is that it is not as 'self-documenting' and also maybe that sometimes one would really want 'inref' (like const & in C++)?

<I hope I'm not confusing things more here with that 'inref' part>

I *think* from Walter's POV, he wants in/out/inout to only describe the intent and doesn't want to get into the source-code level optimization implications of things like 'byref', preferring instead to let compiler implementations battle that out.

Kind-of like D not having 'inline' - I think 'byref' or some form of 'inref' would be adding a keyword to the language that optimizing compilers can generally do a good job of figuring out as it's something that is becoming well understood (like inline) by compiler developers.

*If* that is Walter's POV, then I'd have to agree with him, I guess, because sprinkling C++ code with 'const &' everywhere for performance reasons sucks.

In other words, just use 'in' for now and if DMD doesn't perform as well, try GDC and bitch about the performance of DMD ;)

FWIW, a few months ago I agreed with your sentiment but now I think it is an area that should be addressed by the compiler optimizer if possible.

- Dave

On Fri, 17 Feb 2006 07:00:49 -0800, S. Chancellor <dnewsgr@mephit.kicks-ass.org> wrote:
> On 2006-02-16 23:46:37 -0800, "Regan Heath" <regan@netwin.co.nz> said:
>
>>> If you don't think that was his intention, why didn't he make it a byref  keyword to begin with?
>>  Because we have pointers. :)
>
> We have in, out and inout too!  Why use pointers if we don't have to?

My point is that you _do_ have to use pointers. A pointer _is_ how you pass a struct by reference. Yes, we could add _another_ way to do that, but why? what does it add? It doesn't make the function declaration any clearer. It doesn't provide any more protection.

>>> Why have in, inout, and out?  Why even have out? It's hardly worth it to  have out since it doesn't do hardly anything anyways.  In fact it adds  overhead by setting the parameter to it's initializer.
>>  The behaviour of 'out' achieves much the same thing as the auto  initialising of other D variables. It makes it easier to debug when a  function has forgotten to set it. I agree, it also tells the caller what  to expect. I agree with your original statement WRT 'out', making the code  clearer is "one of the reasons" for it.
>>  I do not believe the same argument applies to "byref". It adds nothing  that a pointer does not already give us. If in the future we have some  sort of data protection scheme and if that scheme requires a keyword in  function declarations then "byref" just might be it.
>
> I didn't ask for a ByRef keyword, I asked for a method for an in keyword to be by reference.

You have one, a pointer.

>>> Does having in/out/inout make coding more clear than just ByRef?
>>  I agree, in/out/inout make coding clearer.
>
> Wouldn't it be consistent then to have a sort of "inbyref" parameter?

No.

> Wouldn't that be consistent with the rest of D style, rather then a pointer, which is just vague and C-esque?

How is a pointer vague?

>>> If so, does using inout where you are not using the parameter as both an  in and an out parameter obfuscate things?
>>  Yes, which is why I use a pointer. A pointer passes data 'in' by  reference. Yes, you can change the data it points to, but it is no  different to a class or array reference passed 'in'.
>
> Pointers are a break from normal D style.  One of the goals of D is to provide programmers access to things like pointers, while making it so they don't have to use them 90% of the time.

Which is exactly what you have. You only need a pointer when you're passing a structure by reference, which, is probably around 10% of the time depending on the sort of stuff you're doing.

>>> D has an ever expanding plethora of features which are useless to quite  a few people.  More being added by the minute, why not a simple aliased  keyword?
>>  So.. your argument for a 'useless' feature is that there are plenty of  other 'useless' features, why not add another one?
>
> If that's what you want to read...

I was asking for clarification by stating the argument as I read it.

> I said there are plenty of features that are useful to quite a few people.

No you didn't, you said the opposite:
>>> D has an ever expanding plethora of features which are useless to quite  a few people.

Then you went on to say:
>>> More being added by the minute, why not a simple aliased  keyword?

which suggested to me that you were saying "one more useless feature can't hurt" or similar. If that was not your intention, sorry, that is how I read it.

> This one is apparently useless to you.

My position is that it's totally useless, it adds nothing a pointer does not already give us.

Regan

On Sat, 18 Feb 2006 02:41:28 +1100, Derek Parnell <derek@psych.ward> wrote:
> The original poster, I think, was just saying it would be useful to have another option available for those things that are currently passed by value, and that option being that we can specify that instead of being passed by value that we want it to be passed by reference *and* that we don't want to use pointer notation to do that.

What I want to know is why not use a pointer? A pointer says to me: pass a reference to <thing>. What is wrong with using a pointer? A pointer is no more or less dangerous than a reference in this usage/case. D allows us to access members using '.' so the code looks no different whether a pointer is passed or a reference or a value. I can't see the downside... unless it's simply an aversion to them due to the danger they can represent in other cases typically in C.

Regan

On Fri, 17 Feb 2006 18:48:49 +0000 (UTC), S. Chancellor <S._member@pathlink.com> wrote:
> In article <op.s44i7ehj6b8z09@ginger.vic.bigpond.net.au>, Derek Parnell says...
>>
>> The original poster, I think, was just saying it would be useful to have
>> another option available for those things that are currently passed by
>> value, and that option being that we can specify that instead of being
>> passed by value that we want it to be passed by reference *and* that we
>> don't want to use pointer notation to do that.
>
> Being the original poster, I can say this is almost exactly what I meant!
> At least someone understands what I was talking about!

I have understood what you're suggesting since your original post, my only problem is that "byref" seems to be a duplication of what a pointer gives us for no benefit.

> Also, I was stating not only that we don't want to use pointers, but we also don't want to use inout, because inout means we're going to change the value.

I agree we certainly don't want 'inout' but what reason do you have for not using a pointer?

Regan

On Sat, 18 Feb 2006 14:56:47 +1100, Regan Heath <regan@netwin.co.nz> wrote:

> On Sat, 18 Feb 2006 02:41:28 +1100, Derek Parnell <derek@psych.ward> wrote:
>> The original poster, I think, was just saying it would be useful to have another option available for those things that are currently passed by value, and that option being that we can specify that instead of being passed by value that we want it to be passed by reference *and* that we don't want to use pointer notation to do that.
>
> What I want to know is why not use a pointer?

I'm probably reading into this, but maybe what's being requested is a special sort of pointer. One that allows you to use it to fetch data with, but does not allow to use it to store data. In other words, one that (pretends?) to point to read-only RAM.

-- 
Derek Parnell
Melbourne, Australia

On Sat, 18 Feb 2006 16:35:40 +1100, Derek Parnell <derek@psych.ward> wrote:
> On Sat, 18 Feb 2006 14:56:47 +1100, Regan Heath <regan@netwin.co.nz> wrote:
>
>> On Sat, 18 Feb 2006 02:41:28 +1100, Derek Parnell <derek@psych.ward> wrote:
>>> The original poster, I think, was just saying it would be useful to have another option available for those things that are currently passed by value, and that option being that we can specify that instead of being passed by value that we want it to be passed by reference *and* that we don't want to use pointer notation to do that.
>>
>> What I want to know is why not use a pointer?
>
> I'm probably reading into this, but maybe what's being requested is a special sort of pointer. One that allows you to use it to fetch data with, but does not allow to use it to store data. In other words, one that (pretends?) to point to read-only RAM.

I believe we've been there before and discovered that it's simply not possible to implement this, or rather that Walter could implement C++ "const" but is not happy that C++ "const" actually solves the problem. That a partial solution doesn't cover enough, or not enough for many people.

I thought we'd come to that conclusion (again) in this thread. And that "byref" was being proposed regardless. Am I mistaken?

If not, my question is simply. What does "byref" add that a pointer does not? because from what I can see it's identical except for the keyword "byref" and the * character in the pointer syntax.

To my mind a function taking a pointer, eg.

struct A {}
void foo(A* ptr) {}

says, takes a reference/pointer to an A. Isn't that what "byref" means?

void foo(byref A ptr) {}

So, if they mean the same thing, and they do the same thing... I prefer the pointer, it's known, it's shorter and easier to type, it exists already.

Regan

On Sat, 18 Feb 2006 20:18:05 +1300, Regan Heath <regan@netwin.co.nz> wrote:
> On Sat, 18 Feb 2006 16:35:40 +1100, Derek Parnell <derek@psych.ward> wrote:
>> On Sat, 18 Feb 2006 14:56:47 +1100, Regan Heath <regan@netwin.co.nz> wrote:
>>
>>> On Sat, 18 Feb 2006 02:41:28 +1100, Derek Parnell <derek@psych.ward> wrote:
>>>> The original poster, I think, was just saying it would be useful to have another option available for those things that are currently passed by value, and that option being that we can specify that instead of being passed by value that we want it to be passed by reference *and* that we don't want to use pointer notation to do that.
>>>
>>> What I want to know is why not use a pointer?
>>
>> I'm probably reading into this, but maybe what's being requested is a special sort of pointer. One that allows you to use it to fetch data with, but does not allow to use it to store data. In other words, one that (pretends?) to point to read-only RAM.
>
> I believe we've been there before and discovered that it's simply not possible to implement this, or rather that Walter could implement C++ "const" but is not happy that C++ "const" actually solves the problem. That a partial solution doesn't cover enough, or not enough for many people.
>
> I thought we'd come to that conclusion (again) in this thread. And that "byref" was being proposed regardless. Am I mistaken?

To clarify. My impression of the proposal is that "byref" would cause a value type to be passed by reference and that it would not guarantee or attempt any protection whatsoever.

Regan

On 2006-02-17 19:49:59 -0800, "Regan Heath" <regan@netwin.co.nz> said:

>> If that's what you want to read...
> 
> I was asking for clarification by stating the argument as I read it.

No, you stated my argument in and altered form.  I stated:
"D has an ever expanding plethora of features which are useless to  quite  a few people. "
Note the choosing of the phrase: "Quite a few people."  Note that I did not say "All People."
My argument is that while complex features which I will never use, such as complex types,
are in D, while some sort of "inref" which is much simpler to add is not.

> 
>> I said there are plenty of features that are useful to quite a few  people.
> 
> No you didn't, you said the opposite:
>>>> D has an ever expanding plethora of features which are useless to  quite  a few people.

That was supposed to read:
I said there are plenty of features that are NOT useful to quite a few  people.

> 
> Then you went on to say:
>>>> More being added by the minute, why not a simple aliased  keyword?
> 
> which suggested to me that you were saying "one more useless feature can't  hurt" or similar. If that was not your intention, sorry, that is how I  read it.

See above to what I said.  You implied something other than what I said by rephrasing my argument and then you tried to get me to agree with the rephrased and incorrect statement.

> 
>> This one is apparently useless to you.
> 
> My position is that it's totally useless, it adds nothing a pointer does  not already give us.

It's either totally useless, or it's your opinion, not both.

-S.

On 2006-02-17 19:58:09 -0800, "Regan Heath" <regan@netwin.co.nz> said:

> On Fri, 17 Feb 2006 18:48:49 +0000 (UTC), S. Chancellor  <S._member@pathlink.com> wrote:
>> In article <op.s44i7ehj6b8z09@ginger.vic.bigpond.net.au>, Derek Parnell  says...
>>> 
>>> The original poster, I think, was just saying it would be useful to have
>>> another option available for those things that are currently passed by
>>> value, and that option being that we can specify that instead of being
>>> passed by value that we want it to be passed by reference *and* that we
>>> don't want to use pointer notation to do that.
>> 
>> Being the original poster, I can say this is almost exactly what I meant!
>> At least someone understands what I was talking about!
> 
> I have understood what you're suggesting since your original post, my only  problem is that "byref" seems to be a duplication of what a pointer gives  us for no benefit.
> 
>> Also, I was stating not only that we don't want to use pointers, but we  also don't want to use inout, because inout means we're going to change  the value.
> 
> I agree we certainly don't want 'inout' but what reason do you have for  not using a pointer?

Because pointers are vague!  Not only that, D set the precedent for new parameter passing syntax with in/inout/out and you need to break from that to use pointers.  Thirdly D also set a precedent by treating pointers as a new type (D changed declarations so that pointers are with the type rather than the instance now.) Presuming that a int* is a different type, then what you are saying is that you want something other than an int to manipulate. That's untrue though.

So, when using a pointer in D you are doing a few things.  You are being vague about what you do to the original value.  You also want to deal with a pointer to an int, and not actually an int. While in some cases this is the case, most of the time all you wanted was the value.

Note that you can have parameters of type in that are pointers,  since pointers are associated with variable types, and not passing method.

-S.

On 2006-02-17 23:20:14 -0800, "Regan Heath" <regan@netwin.co.nz> said:

> On Sat, 18 Feb 2006 20:18:05 +1300, Regan Heath <regan@netwin.co.nz> wrote:
>> On Sat, 18 Feb 2006 16:35:40 +1100, Derek Parnell <derek@psych.ward>  wrote:
>>> On Sat, 18 Feb 2006 14:56:47 +1100, Regan Heath <regan@netwin.co.nz>  wrote:
>>> 
>>>> On Sat, 18 Feb 2006 02:41:28 +1100, Derek Parnell <derek@psych.ward>  wrote:
>>>>> The original poster, I think, was just saying it would be useful to  have another option available for those things that are currently  passed by value, and that option being that we can specify that  instead of being passed by value that we want it to be passed by  reference *and* that we don't want to use pointer notation to do that.
>>>> 
>>>> What I want to know is why not use a pointer?
>>> 
>>> I'm probably reading into this, but maybe what's being requested is a  special sort of pointer. One that allows you to use it to fetch data  with, but does not allow to use it to store data. In other words, one  that (pretends?) to point to read-only RAM.
>> 
>> I believe we've been there before and discovered that it's simply not  possible to implement this, or rather that Walter could implement  C++ "const" but is not happy that C++ "const" actually solves the  problem. That a partial solution doesn't cover enough, or not enough for  many people.
>> 
>> I thought we'd come to that conclusion (again) in this thread. And that  "byref" was being proposed regardless. Am I mistaken?
> 
> To clarify. My impression of the proposal is that "byref" would cause a  value type to be passed by reference and that it would not guarantee or  attempt any protection whatsoever.

That is correct.  That's not to say that protections would be unwelcomed if they were implementable, or good ones could be defined.

-S.