• Gor Gyolchanyan (32/32) Jun 06 2012 I had this idea for a long time now and was trying to find a reason
• Dmitry Olshansky (11/40) Jun 06 2012 There is. For one thing I like pointer for being explicit about
• Gor Gyolchanyan (12/58) Jun 06 2012 s
• Paulo Pinto (9/23) Jun 06 2012 I never had any issue with this in the Pascal language family.
• Nathan M. Swan (8/49) Jun 06 2012 Here's a consideration: when I was a beginner learning C++ the

Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:

I had this idea for a long time now and was trying to find a reason
why it was a bad idea.
I failed to find that reason, so here it is:

The idea is to have a mutable reference:

int& a; // This is a mutable reference (essentially a pointer, but
with reversed behavior).
assert(&a is null); // the address must be taken before
address-related operations can be performed
a = 20; // Access violation error due to null pointer dereferencing.
&a = new int; // Addresses, taken from mutable references are lvalues.
a = 20;
assert(a == 20);
&c = null;
assert(&c is null);

The idea here is to further reduce the need to explicitly deal with
addresses, while providing the number one reason why people use
pointers: indirection.
This mechanism will exclude indirection from the list of reasons why
one would use pointers.
This is also good for reducing compiler magic, when dealing with ref
parameters and return types for functions.
This mutable reference would be the complete compliment of pointers:
dereferencing a pointer yields a mutable reference, taking address of
a mutable reference yields a mutable pointer.

This is not a proposition to add to D, but rather an idea, which could
eventually end up in D if you guys think it's worth it.
It could also be used to remove the magic from reference types, by
adding their non-reference counter-parts and have their "constructors"
return such a mutable reference.

-- 
Bye,
Gor Gyolchanyan.

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

On 06.06.2012 15:45, Gor Gyolchanyan wrote:
 I had this idea for a long time now and was trying to find a reason
 why it was a bad idea.
 I failed to find that reason, so here it is:

There is. For one thing I like pointer for being explicit about 
dereferencing something. In this sense having ref arguments of function 
is IMO step backwards:
mutator(a, b);
vs
mutator(a, &b);

which one more likely to mutate arguments?
In today's D you'll never know.

 The idea is to have a mutable reference:

 int&  a; // This is a mutable reference (essentially a pointer, but
 with reversed behavior).
 assert(&a is null); // the address must be taken before
 address-related operations can be performed
 a = 20; // Access violation error due to null pointer dereferencing.
 &a = new int; // Addresses, taken from mutable references are lvalues.
 a = 20;
 assert(a == 20);
 &c = null;
 assert(&c is null);

 The idea here is to further reduce the need to explicitly deal with
 addresses, while providing the number one reason why people use
 pointers: indirection.
 This mechanism will exclude indirection from the list of reasons why
 one would use pointers.
 This is also good for reducing compiler magic, when dealing with ref
 parameters and return types for functions.
 This mutable reference would be the complete compliment of pointers:
 dereferencing a pointer yields a mutable reference, taking address of
 a mutable reference yields a mutable pointer.

 This is not a proposition to add to D, but rather an idea, which could
 eventually end up in D if you guys think it's worth it.
 It could also be used to remove the magic from reference types, by
 adding their non-reference counter-parts and have their "constructors"
 return such a mutable reference.


-- 
Dmitry Olshansky

Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:

On Wed, Jun 6, 2012 at 3:58 PM, Dmitry Olshansky <dmitry.olsh gmail.com> wr=
ote:
 On 06.06.2012 15:45, Gor Gyolchanyan wrote:
 I had this idea for a long time now and was trying to find a reason
 why it was a bad idea.
 I failed to find that reason, so here it is:

 There is. For one thing I like pointer for being explicit about
 dereferencing something. In this sense having ref arguments of function i=

s
 IMO step backwards:
 mutator(a, b);
 vs
 mutator(a, &b);

 which one more likely to mutate arguments?
 In today's D you'll never know.


 The idea is to have a mutable reference:

 int& =C2=A0a; // This is a mutable reference (essentially a pointer, but
 with reversed behavior).
 assert(&a is null); // the address must be taken before
 address-related operations can be performed
 a =3D 20; // Access violation error due to null pointer dereferencing.
 &a =3D new int; // Addresses, taken from mutable references are lvalues.
 a =3D 20;
 assert(a =3D=3D 20);
 &c =3D null;
 assert(&c is null);

 The idea here is to further reduce the need to explicitly deal with
 addresses, while providing the number one reason why people use
 pointers: indirection.
 This mechanism will exclude indirection from the list of reasons why
 one would use pointers.
 This is also good for reducing compiler magic, when dealing with ref
 parameters and return types for functions.
 This mutable reference would be the complete compliment of pointers:
 dereferencing a pointer yields a mutable reference, taking address of
 a mutable reference yields a mutable pointer.

 This is not a proposition to add to D, but rather an idea, which could
 eventually end up in D if you guys think it's worth it.
 It could also be used to remove the magic from reference types, by
 adding their non-reference counter-parts and have their "constructors"
 return such a mutable reference.


 --
 Dmitry Olshansky

This is completely dependent on the logic of your code, including the
data type in question. Explicit knowledge of mutability is not
necessary only for value types. Reference types are inherently
mutable. This reference idea just produces a reference version of a
given type. If you're concerned about the mutability - use pointers.
This is not a replacement of pointers, but a complement for them.

--=20
Bye,
Gor Gyolchanyan.

"Paulo Pinto" <pjmlp progtools.org> writes:

On Wednesday, 6 June 2012 at 11:58:12 UTC, Dmitry Olshansky wrote:
 On 06.06.2012 15:45, Gor Gyolchanyan wrote:
 I had this idea for a long time now and was trying to find a 
 reason
 why it was a bad idea.
 I failed to find that reason, so here it is:

 There is. For one thing I like pointer for being explicit about 
 dereferencing something. In this sense having ref arguments of 
 function is IMO step backwards:
 mutator(a, b);
 vs
 mutator(a, &b);

 which one more likely to mutate arguments?
 In today's D you'll never know.

I never had any issue with this in the Pascal language family.

You need anyway always to look the function code, as you cannot 
know
what other side-effects might also be affected by the function 
call.

Plus any modern IDE can show the definition as tooltip.

--
Paulo

"Nathan M. Swan" <nathanmswan gmail.com> writes:

On Wednesday, 6 June 2012 at 11:45:34 UTC, Gor Gyolchanyan wrote:
 I had this idea for a long time now and was trying to find a 
 reason
 why it was a bad idea.
 I failed to find that reason, so here it is:

 The idea is to have a mutable reference:

 int& a; // This is a mutable reference (essentially a pointer, 
 but
 with reversed behavior).
 assert(&a is null); // the address must be taken before
 address-related operations can be performed
 a = 20; // Access violation error due to null pointer 
 dereferencing.
 &a = new int; // Addresses, taken from mutable references are 
 lvalues.
 a = 20;
 assert(a == 20);
 &c = null;
 assert(&c is null);

 The idea here is to further reduce the need to explicitly deal 
 with
 addresses, while providing the number one reason why people use
 pointers: indirection.
 This mechanism will exclude indirection from the list of 
 reasons why
 one would use pointers.
 This is also good for reducing compiler magic, when dealing 
 with ref
 parameters and return types for functions.
 This mutable reference would be the complete compliment of 
 pointers:
 dereferencing a pointer yields a mutable reference, taking 
 address of
 a mutable reference yields a mutable pointer.

 This is not a proposition to add to D, but rather an idea, 
 which could
 eventually end up in D if you guys think it's worth it.
 It could also be used to remove the magic from reference types, 
 by
 adding their non-reference counter-parts and have their 
 "constructors"
 return such a mutable reference.

Here's a consideration: when I was a beginner learning C++ the 
difference between reference and pointer types (and their 
operators) confused me so much I avoided learning what pointers 
were for a long time:

type     create from t
T* ptr = &t
T& ref = t