Bug 4272 – x.typeof syntax

A syntax like x.typeof can be considered. There are situations where you will need to parenthesize anyway, like: import std.stdio; void main() { int x = 1; float y = 1.5; writeln(typeid(typeof(x + y))); } You will have to write: (x + y).typeof But in many situations with this change you will be able to avoid the (). This syntax is more similar/uniform to the x.sizeof syntax too (that is sizeof(x) in C).

Then typeid should probably also be .typeid instead of typeid()

*** Issue 8661 has been marked as a duplicate of this issue. ***

typeof isn't a property or a function, unlike sizeof. It's like an is-expression, and I think that treating it like a property would be a mistake.

(In reply to comment #3) > typeof isn't a property or a function, unlike sizeof. It's like an > is-expression, and I think that treating it like a property would be a mistake. I think (x + y).typeof should not be allowed, use the existing syntax instead. However, x.typeof is a useful shorthand that helps cut down on nested brackets in is expressions and elsewhere. So I would allow both typeof(expression) and identifier.typeof to be used, but *not* expression.typeof. The type of an instance is a natural property of the instance IMO.

(In reply to comment #4) > (In reply to comment #3) > > typeof isn't a property or a function, unlike sizeof. It's like an > > is-expression, and I think that treating it like a property would be a mistake. > > I think (x + y).typeof should not be allowed, use the existing syntax instead. > > However, x.typeof is a useful shorthand that helps cut down on nested brackets > in is expressions and elsewhere. So I would allow both typeof(expression) and > identifier.typeof to be used, but *not* expression.typeof. > > The type of an instance is a natural property of the instance IMO. The problem is that UFCS was made to work with functions and typeof is not a function. Accepting identifier.typeof would result in questions about which identifiers are valid for this and what else works besides typeof with them.

(In reply to comment #5) > The problem is that UFCS was made to work with functions and typeof is not a > function. Accepting identifier.typeof would result in questions about which > identifiers are valid for this and what else works besides typeof with them. This is not to do with UFCS. There are already many built in properties like x.sizeof, x.init: http://dlang.org/property.html typeof fits nicely as a built in property, and helps cut down on nested brackets.

(In reply to comment #6) > (In reply to comment #5) > > The problem is that UFCS was made to work with functions and typeof is not a > > function. Accepting identifier.typeof would result in questions about which > > identifiers are valid for this and what else works besides typeof with them. > > This is not to do with UFCS. There are already many built in properties like > x.sizeof, x.init: > http://dlang.org/property.html > > typeof fits nicely as a built in property, and helps cut down on nested > brackets. Typeof is not a property either. And it differs from all those properties which, given a type or expression, provide fundamental information about their types like size, default value, name, alignment. Typeof works in opposite direction - given some expression it gives its type. BTW, identifier is a primary expression (http://dlang.org/expression.html), so, making idenfier.typeof possible and expression.typeof not (as mentioned above), raises some questions. However, if typeof is made a property too, it would be logical and consistent.

Closing this as there is not sufficient evidence that this will improve anything and special casing for symbols is not the way to go.