• S. Chancellor (10/10) Jan 03 2006 I want to voice my opinion on .sizeof, .mangleof and all the other `*of`
• F (7/17) Jan 03 2006 I think Walter choose to rename .size (as initially was) to .sizeof in o...
• Chris Sauls (9/18) Jan 03 2006 While generally you make a point, the reason that 'tyepof()' isn't a pro...
• Craig Black (5/9) Jan 03 2006 But couldn't the following be treated the same way? It is, perhaps, mor...
• Sean Kelly (3/12) Jan 03 2006 Perhaps, but sizeof is evaluated at compile time as well.
• Craig Black (3/4) Jan 03 2006 This does seem odd. If it doesn't overcomplicate the compiler, then typ...
• Matthew (4/7) Jan 03 2006 typeof
• S. Chancellor (4/12) Jan 03 2006 Wouldn't that clutter up the namespace with all the properties from floa...
• Chris Miller (4/19) Jan 03 2006 I think he means just the "*of" ones (mangleof,sizeof...) that apply to ...
• Chris Sauls (3/16) Jan 04 2006 Actually, that's not a bad idea at all, at least for the *of() ops. Mis...
• Walter Bright (4/13) Jan 03 2006 That leads to parsing problems, unfortunately, as it becomes difficult t...
• Roberto Mariottini (5/11) Jan 04 2006 Walter, what do you think about my idea of (optionally) disambiguating

S. Chancellor<dnewsgr mephit.kicks-ass.org> writes:

I want to voice my opinion on .sizeof, .mangleof and all the other `*of`
properties.   They don't make a whole lot of sense.  sizeof(<var>)
makes sense.  var.size makes sense.  var.sizeof, however, seems lacking as
nothing comes after the of.
Also, why isn't typeof() a property? I'm assuming it has something to do
with the fact that it's evaluated at compile-time instead of runtime. 
However, I still think that var.type would be a lot more consistent.
My 2 cents, thanks for listening.

-- 
Email works.

F <F_member pathlink.com> writes:

I think Walter choose to rename .size (as initially was) to .sizeof in order to
avoid conflicts when porting C code, where "size" was a common variable name
while "sizeof" wasn't (since it was a function).
I have an ambiguous opinion im my head about that, but I admit that .size would
be more (human language) coherent.

F



In article <dpe6fj$edf$1 digitaldaemon.com>, S. Chancellor says...
I want to voice my opinion on .sizeof, .mangleof and all the other `*of`
properties.   They don't make a whole lot of sense.  sizeof(<var>)
makes sense.  var.size makes sense.  var.sizeof, however, seems lacking as
nothing comes after the of.
Also, why isn't typeof() a property? I'm assuming it has something to do
with the fact that it's evaluated at compile-time instead of runtime. 
However, I still think that var.type would be a lot more consistent.
My 2 cents, thanks for listening.

-- 
Email works.

Chris Sauls <ibisbasenji gmail.com> writes:

S. Chancellor wrote:
 I want to voice my opinion on .sizeof, .mangleof and all the other `*of`
 properties.   They don't make a whole lot of sense.  sizeof(<var>)
 makes sense.  var.size makes sense.  var.sizeof, however, seems lacking as
 nothing comes after the of.
 Also, why isn't typeof() a property? I'm assuming it has something to do
 with the fact that it's evaluated at compile-time instead of runtime. 
 However, I still think that var.type would be a lot more consistent.
 My 2 cents, thanks for listening.
 

While generally you make a point, the reason that 'tyepof()' isn't a property
is because 
it can be used with expressions, and does *not* evaluate its expression for
more than type 
information.  So, for example:



Here we declare 'var' according to the final type of the given expression, but
*without* 
actually evaluating either 'foo(i)' or 'bar(i)' beyond function-matching and
return-type 
exraction.

-- Chris Sauls

"Craig Black" <cblack ara.com> writes:

 While generally you make a point, the reason that 'tyepof()' isn't a 
 property is because it can be used with expressions, and does *not* 
 evaluate its expression for more than type information.  So, for example:



But couldn't the following be treated the same way?  It is, perhaps, more 
difficult for the compiler to see that the expression should be evaluated at 
compile time?

(foo(i) / bar(j)).typeof var;

-Craig 

Sean Kelly <sean f4.ca> writes:

Craig Black wrote:
 While generally you make a point, the reason that 'tyepof()' isn't a 
 property is because it can be used with expressions, and does *not* 
 evaluate its expression for more than type information.  So, for example:



 
 But couldn't the following be treated the same way?  It is, perhaps, more 
 difficult for the compiler to see that the expression should be evaluated at 
 compile time?

Perhaps, but sizeof is evaluated at compile time as well.


Sean

"Craig Black" <cblack ara.com> writes:

 Perhaps, but sizeof is evaluated at compile time as well.

This does seem odd.  If it doesn't overcomplicate the compiler, then typeof 
should be consistent with the rest of the "*of" family.

-Craig 

"Matthew" <matthew hat.stlsoft.dot.org> writes:

"Craig Black" <cblack ara.com> wrote in message
news:dpek7p$tga$1 digitaldaemon.com...
 Perhaps, but sizeof is evaluated at compile time as well.

 This does seem odd.  If it doesn't overcomplicate the compiler, then

typeof
 should be consistent with the rest of the "*of" family.

My 2 cents: all should be non-member operators, a la typeof.

S. Chancellor <S._member pathlink.com> writes:

In article <dpf5i1$1dp6$1 digitaldaemon.com>, Matthew says...
"Craig Black" <cblack ara.com> wrote in message
news:dpek7p$tga$1 digitaldaemon.com...
 Perhaps, but sizeof is evaluated at compile time as well.

 This does seem odd.  If it doesn't overcomplicate the compiler, then

typeof
 should be consistent with the rest of the "*of" family.

My 2 cents: all should be non-member operators, a la typeof.

Wouldn't that clutter up the namespace with all the properties from float and
whatnot?

-S.

"Chris Miller" <chris dprogramming.com> writes:

On Tue, 03 Jan 2006 20:07:48 -0500, S. Chancellor <S._member pathlink.com>  
wrote:

 In article <dpf5i1$1dp6$1 digitaldaemon.com>, Matthew says...
 "Craig Black" <cblack ara.com> wrote in message
 news:dpek7p$tga$1 digitaldaemon.com...
 Perhaps, but sizeof is evaluated at compile time as well.

 This does seem odd.  If it doesn't overcomplicate the compiler, then

 typeof
 should be consistent with the rest of the "*of" family.

 My 2 cents: all should be non-member operators, a la typeof.

 Wouldn't that clutter up the namespace with all the properties from  
 float and
 whatnot?

 -S.

I think he means just the "*of" ones (mangleof,sizeof...) that apply to  
most everything, and I wouldn't be upset if this switch was made.

Chris Sauls <ibisbasenji gmail.com> writes:

Matthew wrote:
 "Craig Black" <cblack ara.com> wrote in message
 news:dpek7p$tga$1 digitaldaemon.com...
 
Perhaps, but sizeof is evaluated at compile time as well.

This does seem odd.  If it doesn't overcomplicate the compiler, then

 
 typeof
 
should be consistent with the rest of the "*of" family.

 
 
 My 2 cents: all should be non-member operators, a la typeof.

Actually, that's not a bad idea at all, at least for the *of() ops.  Mister
Bright?

-- Chris Sauls

"Walter Bright" <newshound digitalmars.com> writes:

"Craig Black" <cblack ara.com> wrote in message 
news:dpej71$s0i$1 digitaldaemon.com...
 While generally you make a point, the reason that 'tyepof()' isn't a 
 property is because it can be used with expressions, and does *not* 
 evaluate its expression for more than type information.  So, for example:



 But couldn't the following be treated the same way?  It is, perhaps, more 
 difficult for the compiler to see that the expression should be evaluated 
 at compile time?

 (foo(i) / bar(j)).typeof var;

That leads to parsing problems, unfortunately, as it becomes difficult to 
recognize a declaration vs an expression. 

Roberto Mariottini <Roberto_member pathlink.com> writes:

In article <dpet5r$16g0$3 digitaldaemon.com>, Walter Bright says...
"Craig Black" <cblack ara.com> wrote in message 
news:dpej71$s0i$1 digitaldaemon.com...

[...]
 (foo(i) / bar(j)).typeof var;

That leads to parsing problems, unfortunately, as it becomes difficult to 
recognize a declaration vs an expression. 

Walter, what do you think about my idea of (optionally) disambiguating
declarations from expressions?

Ciao