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

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.

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.

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

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

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).