www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Readable "is" expressions

reply Jason House <jason.james.house gmail.com> writes:
Below is my ramblings about long-standind issues with is expressions.  I think
it was inspired by a recent post about how to translate some D 2.x is
expressions into D 1.x...  I have a few thoughts on how I might fix the syntax,
but I'd first like to know if my objections to the current syntax is shared
with others.

According to http://www.digitalmars.com/d/2.0/expression.html#IsExpression,
there are currently 8 forms for is expressions:
  1. is ( Type )
  2. is ( Type : TypeSpecialization )
  3. is ( Type == TypeSepcialization )
  4. is ( Type Identifier )
  5. is ( Type Identifier : TypeSpecialization )
  6. is ( Type Identifier == typeSpecialization )
  7. is ( Type Identifier : TypeSpecialization , TemplateParameterList )
  8. is ( Type Identifier == TypeSpecialization , TemplateParameterList )

I see 3 issues with groking is expressions:
  1. "Type Identifier" does not always create something matching type "Type"
  2. Type Specialization has multple forms
  3. Use of ":" or "==" can be ambiguous, especially when reading code

Issue 1:
  In all other parts of D code, "Type Identifier" creates something matching
"Type".  In an is expression, this is always true with form 4, sometimes true
with forms 5 and 6, and never true with forms 7 and 8.  When it isn't true, the
identifier is reused on the right side fo the ":" or "==" and corresponds to a
derived type.  With enough thinking about an is expression, the meaning should
become clear, but I don't think a casual reader of D code will get it on first
glance.


  Type specialization has three forms:
    A. A pure type
    B. A type with deduction arguments
    C. A keyword representing a class of types
  Form C is not valid for all forms of is expressions (more on this in issue

while form B will have Identifier mean somethign else.  Form B can have up to
one symbol match "identifier", and one or more symbols match inside
TemplateParameterList.  I think there was a recent post to the newsgroup with
an example like is(T U : U*, U) where the identifier U is both the identifier
and part of the TemplateParameterList.


  When reading D code, the meaning of ":" can be ambiguous.  It's a form that
does not match any languages that I know of.  Unlike ":", the meaning of "=="
is clear when reading code.  ":" can be translated as "is implicitly castable
to" and "==" can be translated "is equal to".  
  When writing code, an ambiguity pops up when a keyword TypeSpecialization
(form C above) is used.  is(T:struct) and is(T==struct) can make sense.  In my
mind, T is part of the larger group of structs, just like a short is part of
the larger groups of integers (and is implicitly castable to int because of
this).  That implies to me that the syntax should be is(T:struct), but this is
not correct.  The D syntax is is(T==struct)
Mar 07 2008
parent reply Ty Tower <tytower hotmail.com> writes:
While you are looking at " is "

How hard is it to use the statement "is!" (reads is not)
instead of "!is" (reads not is)
Mar 07 2008
parent reply Darryl Bleau <user example.net> writes:
Ty Tower wrote:

 While you are looking at " is "
 
 How hard is it to use the statement "is!" (reads is not)
 instead of "!is" (reads not is)


Think of it as prefix-negation, like 'competent' and 'incompetent'.
Mar 07 2008
parent Ty Tower <tytower hotmail.com.au> writes:
Darryl Bleau Wrote:


 Ty Tower wrote:

 While you are looking at " is "
 
 How hard is it to use the statement "is!" (reads is not)
 instead of "!is" (reads not is)


 
 Think of it as prefix-negation, like 'competent' and 'incompetent'.


like           is    inis            still sounds like       not is          
to me
Mar 07 2008