Look at this code:

void main(){
  C c=new C;

  printf("%u %u\n", c.size, c.f.size);
}

If you think, that sizes, i.e. byte allocations, of `c' and `c.f' are evaluated and printed, then you are wrong, because this is the code for `C':

class C{
  struct data{
    real value;
    int size;
  }
  data d;
  public data f(){
    return d;
  }
  public int size(){return 0;}
}

Shouldn't the properties of the standard types be turned into keywords?

So long.

"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:bva9np$bnb$1@digitaldaemon.com...
> Look at this code:
>
> void main(){
>   C c=new C;
>
>   printf("%u %u\n", c.size, c.f.size);
> }
>
> If you think, that sizes, i.e. byte allocations, of `c' and `c.f' are evaluated and printed, then you are wrong, because this is the code for `C':
>
> class C{
>   struct data{
>     real value;
>     int size;
>   }
>   data d;
>   public data f(){
>     return d;
>   }
>   public int size(){return 0;}
> }
>
> Shouldn't the properties of the standard types be turned into keywords?

I once proposed using .sizeof for the size property, which while not a keyword in D, *is* a keyword in C and hence won't be in any C structs. It is implemented, you can use .sizeof instead.

"Walter" <walter@digitalmars.com> wrote in message news:bvblhh$2lpc$3@digitaldaemon.com...
>
> "Manfred Nowak" <svv1999@hotmail.com> wrote in message news:bva9np$bnb$1@digitaldaemon.com...
> > Look at this code:
> >
> > void main(){
> >   C c=new C;
> >
> >   printf("%u %u\n", c.size, c.f.size);
> > }
> >
> > If you think, that sizes, i.e. byte allocations, of `c' and `c.f' are evaluated and printed, then you are wrong, because this is the code for `C':
> >
> > class C{
> >   struct data{
> >     real value;
> >     int size;
> >   }
> >   data d;
> >   public data f(){
> >     return d;
> >   }
> >   public int size(){return 0;}
> > }
> >
> > Shouldn't the properties of the standard types be turned into keywords?
>
> I once proposed using .sizeof for the size property, which while not a keyword in D, *is* a keyword in C and hence won't be in any C structs. It
is
> implemented, you can use .sizeof instead.

I knew that. I also thought .size had been dropped. Is that not so? Leaving it in seems to be asking for trouble

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bvc11u$851$1@digitaldaemon.com...
> I knew that. I also thought .size had been dropped. Is that not so?
Leaving
> it in seems to be asking for trouble

Perhaps it's best to leave it as 'deprecated' for the moment, to avoid breaking existing code.

Nah. We're pre 1.0.

Break away!

Anyone complains, and I'll fight em with ya

:)


"Walter" <walter@digitalmars.com> wrote in message news:bvcd8g$rp1$3@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bvc11u$851$1@digitaldaemon.com...
> > I knew that. I also thought .size had been dropped. Is that not so?
> Leaving
> > it in seems to be asking for trouble
>
> Perhaps it's best to leave it as 'deprecated' for the moment, to avoid breaking existing code.
>
>

Yah... there's enough accidental breakage, that a little intentional breakage (for a good cause!) won't be a problem.  I'd much rather break things now, and have a clean language later, than keep everything working now and have a cluttered language later.

Sean

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bvcdg8$s4t$1@digitaldaemon.com...
> Nah. We're pre 1.0.
>
> Break away!
>
> Anyone complains, and I'll fight em with ya
>
> :)
>
>
> "Walter" <walter@digitalmars.com> wrote in message news:bvcd8g$rp1$3@digitaldaemon.com...
> >
> > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bvc11u$851$1@digitaldaemon.com...
> > > I knew that. I also thought .size had been dropped. Is that not so?
> > Leaving
> > > it in seems to be asking for trouble
> >
> > Perhaps it's best to leave it as 'deprecated' for the moment, to avoid breaking existing code.

Sean L. Palmer wrote:

>Yah... there's enough accidental breakage, that a little intentional
>breakage (for a good cause!) won't be a problem.  I'd much rather break
>things now, and have a clean language later, than keep everything working
>now and have a cluttered language later.
>
>Sean
>
>"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
>news:bvcdg8$s4t$1@digitaldaemon.com...
>  
>
>>Nah. We're pre 1.0.
>>
>>Break away!
>>
>>Anyone complains, and I'll fight em with ya
>>
>>:)
>>
>>
>>"Walter" <walter@digitalmars.com> wrote in message
>>news:bvcd8g$rp1$3@digitaldaemon.com...
>>    
>>
>>>"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
>>>news:bvc11u$851$1@digitaldaemon.com...
>>>      
>>>
>>>>I knew that. I also thought .size had been dropped. Is that not so?
>>>>        
>>>>
>>>Leaving
>>>      
>>>
>>>>it in seems to be asking for trouble
>>>>        
>>>>
>>>Perhaps it's best to leave it as 'deprecated' for the moment, to avoid
>>>breaking existing code.
>>>      
>>>
>
>
>  
>
If it's going to be broken, it would be helpful to have a list of "broken" things on the website.   That would include the op operators.  This makes it easier for newbie's to fix old D programs.  I know there's the change log, but often it's not explanative enough (where does it say that all operators have op added to the front?).

-- 
-Anderson: http://badmama.com.au/~anderson/

Sounds like a great idea.

Sean

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:bvd77u$2896$1@digitaldaemon.com...
> Sean L. Palmer wrote:
>
> >Yah... there's enough accidental breakage, that a little intentional breakage (for a good cause!) won't be a problem.  I'd much rather break things now, and have a clean language later, than keep everything working now and have a cluttered language later.
> >
> >Sean

> If it's going to be broken, it would be helpful to have a list of "broken" things on the website.   That would include the op operators. This makes it easier for newbie's to fix old D programs.  I know there's the change log, but often it's not explanative enough (where does it say that all operators have op added to the front?).

Walter wrote:

>> Shouldn't the properties of the standard types be turned into keywords?
> I once proposed using .sizeof for the size property, which while not a keyword in D, *is* a keyword in C and hence won't be in any C structs. It is implemented, you can use .sizeof instead.

Using `sizeof' is useful for porting C to D.

However, take the example and change every `size' to `sizeof'.

What is the reason to allow class designers to override the semantic of standard properties?

In phobos, stream.d `size' is used for the standard types. Is there a good argument, that `sizeof' will never be used in a library for a derived type?

Why is `sizeof' a keyword in C?

So long.

Manfred Nowak wrote:
> Using `sizeof' is useful for porting C to D.
> 
> However, take the example and change every `size' to `sizeof'.
> 
> What is the reason to allow class designers to override the semantic of standard properties?
> 
> In phobos, stream.d `size' is used for the standard types. Is there a good argument, that `sizeof' will never be used in a library for a derived type?
> 
> Why is `sizeof' a keyword in C?
> 
> So long.

Since D now has the typeof() construct, D could just disallow making these properties a member of instances, and instead make them strictly properties of the type.

foo.size would cease to be 'magic'; we have typeof(foo).size. (which is arguably clearer anyway)  Crisis averted. :)

 -- andy