class Foo
{
   static void prop(inout int x)
   {
      x = 3;
   }
}

int main()
{
   int num = 0;
   printf("num = %d\n", num);
   Foo.prop = num; // Innocent assignment.
   printf("num = %d\n", num);

   return 0;
}


Output:

num = 0
num = 3


Looks a little backwards ;)  just thought I'd mention it.

I guess it is a feature rather than a bug :)

E.g. it allows to implement transfer of ownership.

struct Foo
{
   char[] _buffer;
   void buffer(inout Foo x)
   {
       _buffer = x._buffer;
       x._buffer = null;
    }
}

Huh?


"Vathix" <vathix@dprogramming.com> wrote in message news:op.sqt37ts4kcck4r@esi...
> class Foo
> {
>    static void prop(inout int x)
>    {
>       x = 3;
>    }
> }
>
> int main()
> {
>    int num = 0;
>    printf("num = %d\n", num);
>    Foo.prop = num; // Innocent assignment.
>    printf("num = %d\n", num);
>
>    return 0;
> }
>
>
> Output:
>
> num = 0
> num = 3
>
>
> Looks a little backwards ;)  just thought I'd mention it.

Vathix wrote:
> class Foo
> {
>    static void prop(inout int x)
>    {
>       x = 3;
>    }
> }
> 
> int main()
> {
>    int num = 0;
>    printf("num = %d\n", num);
>    Foo.prop = num; // Innocent assignment.
>    printf("num = %d\n", num);
> 
>    return 0;
> }

That looks extremely counterintuitive to me!

What about this idea? The property syntax Foo.prop = num should only be allowed where prop takes an in argument. If the argument is out or inout, D should force you to use the function syntax Foo.prop(num).

What do you think?

James McComb

On Mon, 16 May 2005 09:28:17 +1000, James McComb wrote:

> Vathix wrote:
>> class Foo
>> {
>>    static void prop(inout int x)
>>    {
>>       x = 3;
>>    }
>> }
>> 
>> int main()
>> {
>>    int num = 0;
>>    printf("num = %d\n", num);
>>    Foo.prop = num; // Innocent assignment.
>>    printf("num = %d\n", num);
>> 
>>    return 0;
>> }
> 
> That looks extremely counterintuitive to me!
> 
> What about this idea? The property syntax Foo.prop = num should only be allowed where prop takes an in argument. If the argument is out or inout, D should force you to use the function syntax Foo.prop(num).
> 
> What do you think?

It's the designer's or coder's choice. If they choose to use inout *and* treat it as an inout parameter, that is their choice, and probably made for a very good reason.

I can't see why we should hobble the language based on 'what is good coding practices'. If that was the case, the GOTO might not live very long ;-) We should permit the language to enhance the coder's freedom of coding practices, even if one doesn't approve of some.

-- 
Derek
Melbourne, Australia
16/05/2005 9:34:02 AM

Derek Parnell wrote:

> I can't see why we should hobble the language based on 'what is good coding
> practices'. If that was the case, the GOTO might not live very long ;-) We
> should permit the language to enhance the coder's freedom of coding
> practices, even if one doesn't approve of some.

Hey, I *like* languages that are hobbled based on what is good coding practices! It's the only way to guarantee that the other members of my team use good pracises (code reviews have no effect on them)! :)

James McComb

Are you paying these people?

Who's to say a class couldn't need this, as Andrew Fedoniouk described?

-[Unknown]


> Derek Parnell wrote:
> 
>> I can't see why we should hobble the language based on 'what is good coding
>> practices'. If that was the case, the GOTO might not live very long ;-) We
>> should permit the language to enhance the coder's freedom of coding
>> practices, even if one doesn't approve of some.
> 
> 
> Hey, I *like* languages that are hobbled based on what is good coding practices! It's the only way to guarantee that the other members of my team use good pracises (code reviews have no effect on them)! :)
> 
> James McComb

On Mon, 16 May 2005 12:19:35 +1000, James McComb wrote:

> Derek Parnell wrote:
> 
>> I can't see why we should hobble the language based on 'what is good coding practices'. If that was the case, the GOTO might not live very long ;-) We should permit the language to enhance the coder's freedom of coding practices, even if one doesn't approve of some.
> 
> Hey, I *like* languages that are hobbled based on what is good coding practices! It's the only way to guarantee that the other members of my team use good pracises (code reviews have no effect on them)! :)

Sack them then! A good team plays by the team rules. When team members from any of my teams have trouble with reviews or following standards, they are told to shape up or ship out. If they persist in bring down the team, they are moved off the team.

A flexible language means that different teams can have different rules and standards. For example, my rules and my standards are not regarded as sufficient by some other people, and unless they are in one of my teams, I'm okay with that. They are free to convince me to change my views, as I believe it is reasonable to assume that my views could possibly be wrong or need updating.

-- 
Derek
Melbourne, Australia
16/05/2005 12:25:08 PM

Unknown W. Brackets wrote:
> Are you paying these people?

No. They're my co-workers.

> Who's to say a class couldn't need this, as Andrew Fedoniouk described?

A class could need that *behaviour*. Why would it need to use property *syntax*, when they could use the less confusing (to me, anyway) function syntax?

James McComb

Ah, there, you said the exact reason - "to me, anyway".  I ain't you.

-[Unknown]


>> Who's to say a class couldn't need this, as Andrew Fedoniouk described?
> 
> 
> A class could need that *behaviour*. Why would it need to use property *syntax*, when they could use the less confusing (to me, anyway) function syntax?
> 
> James McComb

> A class could need that *behaviour*. Why would it need to use property *syntax*, when they could use the less confusing (to me, anyway) function syntax?

There are a lot of languages passing parameters by values only.
So inout parameter in function will be also weird for apologists of these
languages.

There are too many things that you can screw up in C/C++, C#, VB, whatewer.

One might say : lets remove references in C++ as memebers of my team can do:

class Foo {
  void Bar(const T& t) const
  {
     const_cast<Foo*>(this) -> ....
     const_cast<T&>(t). .....
  }
}

All above does not mean that D is perfect at this stage... It is good, but not perfect yet.

Andrew.


"James McComb" <ned@jamesmccomb.id.au> wrote in message news:d698bk$121s$1@digitaldaemon.com...
> Unknown W. Brackets wrote:
>> Are you paying these people?
>
> No. They're my co-workers.
>
>> Who's to say a class couldn't need this, as Andrew Fedoniouk described?
>
> A class could need that *behaviour*. Why would it need to use property *syntax*, when they could use the less confusing (to me, anyway) function syntax?
>
> James McComb