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