www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - import std.traits. std.string;

reply DigitalDesigns <DigitalDesigns gmail.com> writes:
space is ignored! Seems like a bug std . traits . std . string is 
valid?
Jun 15 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Jun 16, 2018 at 12:24:42AM +0000, DigitalDesigns via Digitalmars-d
wrote:

 space is ignored! Seems like a bug std . traits . std . string is valid?


It's not a bug.  The '.' is the member-access operator, and like all
other operators, is allowed to be surrounded by spaces. (Even though
most people don't write it that way.)


T

-- 
People walk. Computers run.
Jun 15 2018
parent DigitalDesigns <DigitalDesigns gmail.com> writes:
On Saturday, 16 June 2018 at 00:34:01 UTC, H. S. Teoh wrote:

 On Sat, Jun 16, 2018 at 12:24:42AM +0000, DigitalDesigns via 
 Digitalmars-d wrote:

 space is ignored! Seems like a bug std . traits . std . string 
 is valid?


 It's not a bug.  The '.' is the member-access operator, and 
 like all other operators, is allowed to be surrounded by 
 spaces. (Even though most people don't write it that way.)


 T


So, what you are saying is that if one does

import std.traits. std.string;

the compiler is parsing that as valid code? Let me ask you why 
you think it is allowed. Is it because it just is or because that 
is the mathematically correct behavior that should be allowed?

BTW, we are not talking about general member access but in 
imports where it can lead to bugs:

import std.traits. foo;

import std.traits.foo;

rather than

import std.traits, foo;

which is most likely what the user desired.

Also, The only time I have ever see people use . is to break on a 
line.  Seems that the rules could be more specific and still get 
all the functionality that people need without creating potential 
sources of bugs.

. in import cannot have spaces.
. as member access cannot have spaces unless it starts the line.

    .atom
    .go
    .now


rather than .

     atom
                  .               go              .
     now


Enforcing a little clarity in the language is not a bad thing.
Jun 15 2018
prev sibling next sibling parent Basile B. <b2.b2.b2.b2.b2.temp.temp gmx.gmx.com> writes:
On Saturday, 16 June 2018 at 00:24:42 UTC, DigitalDesigns wrote:

 space is ignored! Seems like a bug std . traits . std . string 
 is valid?


No, it's not a bug. Tokens are so. Try to write a grammar and a 
lexer, you'll understand that this makes sense.

https://run.dlang.io/is/5YxAwR
Jun 15 2018
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Saturday, 16 June 2018 at 00:24:42 UTC, DigitalDesigns wrote:

 space is ignored! Seems like a bug std . traits . std . string 
 is valid?


Like most C-family languages, D is a freeform language[1]. 
Funnily enough, I don't think this is explicitly stated in the D 
spec (at least not that I could find). It's just assumed, because 
D is an evolution of C, C++, and Java primarily, all of which are 
freeform languages.

There are a couple places where whitespace is significant in D, 
but for the most part, you can write your code in whatever way 
you want as long as it's syntactically valid according to the D 
grammar.

1. 
https://www.pcmag.com/encyclopedia/term/43487/free-form-language
Jun 15 2018
parent Neia Neutuladh <neia ikeran.org> writes:
On Saturday, 16 June 2018 at 06:43:25 UTC, Meta wrote:

 On Saturday, 16 June 2018 at 00:24:42 UTC, DigitalDesigns wrote:

 space is ignored! Seems like a bug std . traits . std . string 
 is valid?


 Like most C-family languages, D is a freeform language[1]. 
 Funnily enough, I don't think this is explicitly stated in the 
 D spec (at least not that I could find). It's just assumed, 
 because D is an evolution of C, C++, and Java primarily, all of 
 which are freeform languages.


 From the Language → Lexical docs:

"The lexical analysis is independent of the syntax parsing and 
the semantic analysis. The lexical analyzer splits the source 
text up into tokens. The lexical grammar describes the syntax of 
those tokens."

"The source text is decoded from its source representation into 
Unicode Characters. The Characters are further divided into: 
WhiteSpace, EndOfLine, Comments, SpecialTokenSequences, Tokens, 
all followed by EndOfFile."

So a source file contains a number of things, some of them 
tokens. The tokenizer produces a series of tokens from it. The 
parser deals with those tokens. This doesn't state that 
whitespace is ignored; instead, it says that the language only 
pays attention to tokens (and, by implication, not whitespace, or 
comments, or the end of the file, etc).
Jun 17 2018