www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why do some attributes start with ' ' while others done't?

reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
I am puzzled as to why there is  nogc on the one hand and simply 
nothrow on the other? Why are some attributes prefixed with ' ' 
while others aren't?

Regards
Jan 21
next sibling parent reply Brad Anderson <eco gnuk.net> writes:
On Thursday, 21 January 2016 at 23:05:51 UTC, Dibyendu Majumdar 
wrote:
 I am puzzled as to why there is  nogc on the one hand and 
 simply nothrow on the other? Why are some attributes prefixed 
 with ' ' while others aren't?

 Regards
For historical reasons, basically. There have been some calls to make it uniform but nothing has really happened.
Jan 21
parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Thursday, 21 January 2016 at 23:08:07 UTC, Brad Anderson wrote:
 On Thursday, 21 January 2016 at 23:05:51 UTC, Dibyendu Majumdar 
 wrote:
 I am puzzled as to why there is  nogc on the one hand and 
 simply nothrow on the other? Why are some attributes prefixed 
 with ' ' while others aren't?
For historical reasons, basically. There have been some calls to make it uniform but nothing has really happened.
I see. And which approach is considered better? Personally don't see why the ' ' prefix is necessary. Regards
Jan 21
parent reply Brian Schott <briancschott gmail.com> writes:
On Thursday, 21 January 2016 at 23:14:14 UTC, Dibyendu Majumdar 
wrote:
 I see. And which approach is considered better? Personally 
 don't see why the ' ' prefix is necessary.

 Regards
Without the " ", the following valid code would break: bool safe = !aIsDangerous && !bIsDangerous; Every time a new keyword is added to the language some working code will become invalid.
Jan 21
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 21 January 2016 at 23:19:19 UTC, Brian Schott wrote:
 Every time a new keyword is added to the language some working 
 code will become invalid.
Well, technically, since UDAs exist, every new thing is potential breakage too, though of course, limited in scope. (If I was doing it, I'd actually make the ones be implicitly imported names, so you could disambiguate with teh module system like normal if that did happen, but meh.)
Jan 21
parent reply Dicebot <public dicebot.lv> writes:
On Friday, 22 January 2016 at 02:12:27 UTC, Adam D. Ruppe wrote:
 Well, technically, since UDAs exist, every new  thing is 
 potential breakage too, though of course, limited in scope.

 (If I was doing it, I'd actually make the ones be implicitly 
 imported names, so you could disambiguate with teh module 
 system like normal if that did happen, but meh.)
Putting built-in -attributes in a runtime module publicly imported from object.d is a very long proposal but last time it was discussed Walter wasn't convinced it is of much gain AFAIR. May get there eventually, I hope.
Jan 21
parent Jacob Carlborg <doob me.com> writes:
On 2016-01-22 03:23, Dicebot wrote:

 Putting built-in  -attributes in a runtime module publicly imported from
 object.d is a very long proposal but last time it was discussed Walter
 wasn't convinced it is of much gain AFAIR. May get there eventually, I
 hope.
We at least have it for the Objective-C related attribute selector [1]. [1] https://github.com/D-Programming-Language/druntime/blob/master/src/object.d#L52 -- /Jacob Carlborg
Jan 22
prev sibling next sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Thursday, 21 January 2016 at 23:05:51 UTC, Dibyendu Majumdar 
wrote:
 I am puzzled as to why there is  nogc on the one hand and 
 simply nothrow on the other? Why are some attributes prefixed 
 with ' ' while others aren't?

 Regards
Short answer: It's for historical reasons; it would not be done this way today, but cannot be changed without breaking valid code already in the wild. Longer answer: The ones prefixed with are not keywords. This is good, because it means that they are not reserved, and may be used as identifiers as well. This will compile fine: void nogc(int nogc) nogc nothrow { } This won't, though: void nothrow(int nothrow) nogc nothrow { } When the process of designing D began, people didn't realize just how many attributes would end up being added to the language. At some point, it became clear that it was both undesirable and unnecessary to forbid all attribute names from being used for other purposes elsewhere in D's grammar. The solution was to begin prefixing to new attributes. Adding the to the old attributes was discussed as well, but it didn't seem worth the code breakage. A revision of D that wasn't constrained by backwards compatibility would almost certainly either require all attributes to be prefixed by , or change the grammar such that attribute names could be reused as identifier names without introducing ambiguities.
Jan 21
next sibling parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Thursday, 21 January 2016 at 23:18:16 UTC, tsbockman wrote:
 Adding the   to the old attributes was discussed as well, but 
 it didn't seem worth the code breakage.
I have to wonder if it would be that bad, since if you're aware of where it breaks (which source code) wouldn't a bulk search/replace of the sources to resolve that? Although I'll be honest, breaking code is never fun, and making people scour their code to fix something that worked before is just an annoyance. On the other hand I'm almost tempted to suggest a tool that would update changes to source code when some of these things happen, dealing with most of these types of problems.
Jan 21
next sibling parent reply Brian Schott <briancschott gmail.com> writes:
On Thursday, 21 January 2016 at 23:25:01 UTC, Era Scarecrow wrote:
  Although I'll be honest, breaking code is never fun, and 
 making people scour their code to fix something that worked 
 before is just an annoyance. On the other hand I'm almost 
 tempted to suggest a tool that would update changes to source 
 code when some of these things happen, dealing with most of 
 these types of problems.
Yeah. Somebody should write something like that. Waaaait. Hang on. *I* wrote something like that. The problem is that nobody wants to make breaking changes even though dfix exists. https://github.com/Hackerpilot/dfix
Jan 21
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 21 January 2016 at 23:48:03 UTC, Brian Schott wrote:
 Yeah. Somebody should write something like that.

 Waaaait. Hang on. *I* wrote something like that. The problem is 
 that nobody wants to make breaking changes even though dfix 
 exists.

 https://github.com/Hackerpilot/dfix
Perhaps they could begin a process, like adding pure and nothrow. Then, people at least people can update source code at their own pace. I doubt adding those would break much code (which makes me wonder if it would be possible to do something like go through all of the dub repository and estimate if any code would get broken by it).
Jan 21
parent reply Brian Schott <briancschott gmail.com> writes:
On Thursday, 21 January 2016 at 23:58:31 UTC, jmh530 wrote:
 Perhaps they could begin a process, like adding  pure and 
  nothrow. Then, people at least people can update source code 
 at their own pace. I doubt adding those would break much code 
 (which makes me wonder if it would be possible to do something 
 like go through all of the dub repository and estimate if any 
 code would get broken by it).
I wrote up the details of this idea as a DIP many months ago: http://wiki.dlang.org/DIP64 It's already implemented in dfix. You can run "dfix --dip64 file.d" and the changes will be made automatically.
Jan 21
parent reply Dicebot <public dicebot.lv> writes:
On Friday, 22 January 2016 at 00:11:02 UTC, Brian Schott wrote:
 I wrote up the details of this idea as a DIP many months ago:

 http://wiki.dlang.org/DIP64

 It's already implemented in dfix. You can run "dfix --dip64 
 file.d" and the changes will be made automatically.
The problem with DIP64 isn't that it breaks the code but that it doesn't propose any meaningful system as a replacement. "Keywords that are only attributes (i.e. they are not also storage classes or type constructors)" doesn't sound as straightforward to me considering https://dlang.org/spec/declaration.html#StorageClass lists -properties as storage classes and there isn't any other list in spec I could find. There isn't even any strict definition of "storage class" and "type qualifier / type constructor" in language spec that could explain existing classification. For example, I'd definitely place something like ` safe` in type constructors but it seems to be considered a storage class. That was the reason why I was insisting on reverting last attempt to change requirements in dmd - breaking the code can be ok, but not having a clear explanation of new design (and still breaking the code) is not ok at all.
Jan 21
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/22/2016 03:20 AM, Dicebot wrote:
 I'd definitely place something like ` safe` in type constructors
safe(int) ?
Jan 21
parent Dicebot <public dicebot.lv> writes:
On Friday, 22 January 2016 at 03:18:29 UTC, Timon Gehr wrote:
 On 01/22/2016 03:20 AM, Dicebot wrote:
 I'd definitely place something like ` safe` in type 
 constructors
safe(int) ?
Normally I rely on this definition: feature .. builds new types from old ones (https://en.m.wikipedia.org/wiki/Type_constructor) That matches my intuitive expectations. I.e. plain 'extern' is a storage class because for `const int x; extern int y;` type of y is still plain into but x is const(int) safe functions do have distinct type thus I'd expect it to be type qualifier/constructor. However D seems to use different classification that isn't documented anywhere.
Jan 21
prev sibling parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Thursday, 21 January 2016 at 23:48:03 UTC, Brian Schott wrote:
 On Thursday, 21 January 2016 at 23:25:01 UTC, Era Scarecrow 
 wrote:
 I'm almost tempted to suggest a tool that would update changes 
 to source code when some of these things happen, dealing with 
 most of these types of problems.
Waaaait. Hang on. *I* wrote something like that. The problem is that nobody wants to make breaking changes even though dfix exists. https://github.com/Hackerpilot/dfix
If the fixes are easily automated requiring no intervention (other than running a tool) then i would totally push for these changes; Probably have a reminder notes during each release for people unaware of dfix that it will fix these changes to source code. Worst case for not breaking code ultimately goes to users not updating the compiler.
Jan 21
parent Jacob Carlborg <doob me.com> writes:
On 2016-01-22 01:20, Era Scarecrow wrote:

   If the fixes are easily automated requiring no intervention (other
 than running a tool) then i would totally push for these changes;
 Probably have a reminder notes during each release for people unaware of
 dfix that it will fix these changes to source code.

   Worst case for not breaking code ultimately goes to users not updating
 the compiler.
The problem is since we now have user defined attributes we will get the same naming conflicts even if all attributes are prefixed with . -- /Jacob Carlborg
Jan 22
prev sibling next sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Thursday, 21 January 2016 at 23:25:01 UTC, Era Scarecrow wrote:
  I have to wonder if it would be that bad, since if you're 
 aware of where it breaks (which source code) wouldn't a bulk 
 search/replace of the sources to resolve that?
It wouldn't be too bad, as such things go. But it also serves little practical purpose; why break people's code for purely aesthetic reasons?
  Although I'll be honest, breaking code is never fun, and 
 making people scour their code to fix something that worked 
 before is just an annoyance. On the other hand I'm almost 
 tempted to suggest a tool that would update changes to source 
 code when some of these things happen, dealing with most of 
 these types of problems.
https://code.dlang.org/packages/dfix
Jan 21
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 21 January 2016 at 23:48:14 UTC, tsbockman wrote:
 It wouldn't be too bad, as such things go. But it also serves 
 little practical purpose; why break people's code for purely 
 aesthetic reasons?
1. Because it isn't purely aesthetic, it is also a question of usability. 2. Because very little code has been written in D. 3. Because D stands no chance of widespread adoption without fixing the usability issues. 4. Because you can have two parsers in the same compiler, one for legacy source files and one for contemporary code. The only code that will break is code that relies on string mixins, which is a horrible idea anyway. But D should fix all the semantic issues first. Unfortunately there is no focus on this, only on adding new features. IMHO: D is a dying language until there is a focus on bringing both coherent semantics and syntax to the language. It is not like adding C++ linkage without bringing semantics closer to C++ will be a saviour. There is too much focus on having a wide range of 70% solutions with marginal support.
Jan 21
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Friday, 22 January 2016 at 02:13:56 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 21 January 2016 at 23:48:14 UTC, tsbockman wrote:
 It wouldn't be too bad, as such things go. But it also serves 
 little practical purpose; why break people's code for purely 
 aesthetic reasons?
1. Because it isn't purely aesthetic, it is also a question of usability. 2. Because very little code has been written in D. 3. Because D stands no chance of widespread adoption without fixing the usability issues. 4. Because you can have two parsers in the same compiler, one for legacy source files and one for contemporary code. The only code that will break is code that relies on string mixins, which is a horrible idea anyway. But D should fix all the semantic issues first. Unfortunately there is no focus on this, only on adding new features. IMHO: D is a dying language until there is a focus on bringing both coherent semantics and syntax to the language. It is not like adding C++ linkage without bringing semantics closer to C++ will be a saviour. There is too much focus on having a wide range of 70% solutions with marginal support.
I don't necessarily disagree with your overall point, but I think the question of whether a few attributes have an attached to them or not ranks pretty low on the list of "70% solutions with marginal support" that need fixing/fleshing out. If this is truly among the most pressing issues with D, then D must be in great shape. It seems like poor allocation of resources (both those of the D development team, and those of the D users who would be forced to update their code) to put much effort into this right now, when there are so many other issues of greater practical import to work on.
Jan 21
next sibling parent rsw0x <anonymous anonymous.com> writes:
On Friday, 22 January 2016 at 04:30:33 UTC, tsbockman wrote:
 On Friday, 22 January 2016 at 02:13:56 UTC, Ola Fosheim Grøstad 
 wrote:
 [...]
I don't necessarily disagree with your overall point, but I think the question of whether a few attributes have an attached to them or not ranks pretty low on the list of "70% solutions with marginal support" that need fixing/fleshing out. If this is truly among the most pressing issues with D, then D must be in great shape. It seems like poor allocation of resources (both those of the D development team, and those of the D users who would be forced to update their code) to put much effort into this right now, when there are so many other issues of greater practical import to work on.
It's just another straw on the 'language being woefully underdefined/unimplemented' camel right next to shared, SafeD, no defined memory model, etc. What are we plebs supposed to do about such things besides wait around for Walter or Andrei to address it?
Jan 21
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 22 January 2016 at 04:30:33 UTC, tsbockman wrote:
 I don't necessarily disagree with your overall point, but I 
 think the question of whether a few attributes have an   
 attached to them or not ranks pretty low on the list of "70% 
 solutions with marginal support" that need fixing/fleshing out. 
 If this is truly among the most pressing issues with D, then D 
 must be in great shape.
It isn't the most pressing issue. It is an issue that gives newbies an impression that there are rough edges, but that is actually true… so maybe it is kind of honest to have a rough syntax at this stage. In a future updated syntax " " probably should be used for features that are annotation like and that works like UDA for consistency. More like "predefined UDA". Perfect for compiler hints like inlining, loop unrolling etc. Maybe even public/private.
 It seems like poor allocation of resources (both those of the D 
 development team, and those of the D users who would be forced 
 to update their code) to put much effort into this right now, 
 when there are so many other issues of greater practical import 
 to work on.
Indeed, reworking the syntax should be done after the semantics are frozen, otherwise the syntax will never be stable. So it should wait until D has figured out how to deal with "shared" and non-gc memory management. And, IMO, when redoing the syntax one might want to look at contemporary languages like Swift and C# to see if one can lower the barrier to entry for Apple and Microsoft type programmers. I am not sure if looking like C is all that attractive in 2016 as far as recruiting goes. By 2025 C-style syntax might be viewed as arcane among young programmers.
Jan 22
parent reply Wyatt <wyatt.epp gmail.com> writes:
On Friday, 22 January 2016 at 08:23:48 UTC, Ola Fosheim Grøstad 
wrote:
 And, IMO, when redoing the syntax one might want to look at 
 contemporary languages like Swift and C# to see if one can 
 lower the barrier to entry for Apple and Microsoft type 
 programmers.
"Contemporary". ;) Aside from Swift's optional semicolons, they're really not all that different.
 I am not sure if looking like C is all that attractive in 2016 
 as far as recruiting goes. By 2025 C-style syntax might be 
 viewed as arcane among young programmers.
Like Swift, C#, Javascript, Go, Haxe, Rust, Dart, et al? Really, people have been predicting the death of curly-braces languages for decades now, and they're as strong as ever. Do you have anything to base this on, or is it just what you'd (apparently) like to see? -Wyatt
Jan 22
next sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Friday, 22 January 2016 at 15:34:18 UTC, Wyatt wrote:
 On Friday, 22 January 2016 at 08:23:48 UTC, Ola Fosheim Grøstad 
 wrote:
[...]
"Contemporary". ;) Aside from Swift's optional semicolons, they're really not all that different.
 [...]
Like Swift, C#, Javascript, Go, Haxe, Rust, Dart, et al? Really, people have been predicting the death of curly-braces languages for decades now, and they're as strong as ever. Do you have anything to base this on, or is it just what you'd (apparently) like to see? -Wyatt
Maybe it's just me, but without my comfy braces I get lost. Large python files feel like a maze to me honestly. Lispers might have been onto something.
Jan 22
next sibling parent Wyatt <wyatt.epp gmail.com> writes:
On Friday, 22 January 2016 at 15:36:06 UTC, rsw0x wrote:
 Maybe it's just me, but without my comfy braces I get lost. 
 Large python files feel like a maze to me honestly.
 Lispers might have been onto something.
It's not just you; I completely agree. Python (and a lot of ruby) is nearly unreadable to me even with wide tabstops. I have a couple projects I started in Python that I've largely abandoned because of that. :/ I'm not overly attached to semicolons -- I think I could live without them in most cases -- but omitting something to properly denote blocks is a deal-breaker at this point. -Wyatt
Jan 22
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 22 January 2016 at 15:36:06 UTC, rsw0x wrote:
 Maybe it's just me, but without my comfy braces I get lost. 
 Large python files feel like a maze to me honestly.
 Lispers might have been onto something.
That's just conditioning. If you are used to "BEGIN" and "END" picking up braces takes time, same time the other way around. If you use single item per line and a proper IDE they aren't really different. Python's indentation the same, but you need a decent IDE that does proper re-indentation etc.
Jan 22
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Jan 22, 2016 at 06:08:14PM +0000, Ola Fosheim Grstad via Digitalmars-d
wrote:
 On Friday, 22 January 2016 at 15:36:06 UTC, rsw0x wrote:
Maybe it's just me, but without my comfy braces I get lost. Large
python files feel like a maze to me honestly.  Lispers might have
been onto something.
That's just conditioning. If you are used to "BEGIN" and "END" picking up braces takes time, same time the other way around. If you use single item per line and a proper IDE they aren't really different. Python's indentation the same, but you need a decent IDE that does proper re-indentation etc.
IDEs are for wimps. Vim rulez. :-P T -- People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG
Jan 22
prev sibling parent reply Wyatt <wyatt.epp gmail.com> writes:
On Friday, 22 January 2016 at 18:08:14 UTC, Ola Fosheim Grøstad 
wrote:
 That's just conditioning. If you are used to "BEGIN" and "END" 
 picking up braces takes time, same time the other way around.
BEGIN and END are still basically braces and they still serve in the capacity of a visual anchor for a block for humans.
 If you use single item per line and a proper IDE they aren't 
 really different. Python's indentation the same, but you need a 
 decent IDE that does proper re-indentation etc.
If you need an IDE to work comfortably in a language, something has clearly gone wrong. -Wyatt
Jan 22
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 22 January 2016 at 18:28:31 UTC, Wyatt wrote:
 If you need an IDE to work comfortably in a language, something 
 has clearly gone wrong.
In the case of Python what was wrong is that it accepts both tabs and spaces for indentation. It should have required either tabs or spaces. So you basically need a good editor to makes sure that you don't have to deal with that problem. As far as legibility it is the same for me. It took a lot of time for me to get used to "{" instead of "BEGIN". It took a similar amount of time to get used to Python's indentation. So I'd blame that on conditioning (what we are used to).
Jan 22
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Jan 22, 2016 at 06:39:39PM +0000, Ola Fosheim Grstad via Digitalmars-d
wrote:
 On Friday, 22 January 2016 at 18:28:31 UTC, Wyatt wrote:
If you need an IDE to work comfortably in a language, something has
clearly gone wrong.
In the case of Python what was wrong is that it accepts both tabs and spaces for indentation. It should have required either tabs or spaces. So you basically need a good editor to makes sure that you don't have to deal with that problem.
I work with Python code without an IDE, and I manage just fine. As long as you're consistent with how you use tabs vs. spaces, it's not a problem. (Besides, even when it *is* a problem it's not a *big* problem at all -- the interpreter simply bails out and you just edit the offending line and move on. End of story.)
 As far as legibility it is the same for me. It took a lot of time for
 me to get used to "{" instead of "BEGIN". It took a similar amount of
 time to get used to Python's indentation. So I'd blame that on
 conditioning (what we are used to).
While I wouldn't adopt significant whitespace the way Python does if I were to design a language, I don't find Python's indentation requirements that strange at all. After all, if you're using good coding practices you should *already* be using consistent indentation anyway, so you should already be ready to work with Python with minimal changes to your habits. People who complain about Python's "whitespace thing" tend to be people who write unreadable code in the first place; that's no surprise. T -- Change is inevitable, except from a vending machine.
Jan 22
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 22 January 2016 at 19:10:38 UTC, H. S. Teoh wrote:
 I work with Python code without an IDE, and I manage just fine. 
 As long as you're consistent with how you use tabs vs. spaces, 
 it's not a problem. (Besides, even when it *is* a problem it's 
 not a *big* problem at all -- the interpreter simply bails out 
 and you just edit the offending line and move on. End of story.)
Yeah, when I write python, I have my default settings in my text editor replace tabs with spaces. Not a problem. I would agree with others that after writing a bunch of curly brace code, the python code I've written in the past looks weird.
Jan 22
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 22 January 2016 at 19:10:38 UTC, H. S. Teoh wrote:
 I work with Python code without an IDE, and I manage just fine. 
 As long as you're consistent with how you use tabs vs. spaces, 
 it's not a problem.
Yes, if you use the same editor and reformat source files you download before editing them. I have found it to be more convenient to use an editor that auto detects common mistakes (not unique for Python though).
 People who complain about Python's "whitespace thing" tend to 
 be people who write unreadable code in the first place; that's 
 no surprise.
Yes, I don't think it takes more time to get used to that than to get used to braces, but if you nest longer functions within functions it is possible to accidentally have a mis-indented ending. Not a frequent problem, though. Happens with braces too.
Jan 22
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Jan 22, 2016 at 10:11:45PM +0000, Ola Fosheim Grstad via Digitalmars-d
wrote:
 On Friday, 22 January 2016 at 19:10:38 UTC, H. S. Teoh wrote:
I work with Python code without an IDE, and I manage just fine. As
long as you're consistent with how you use tabs vs. spaces, it's not
a problem.
Yes, if you use the same editor and reformat source files you download before editing them. I have found it to be more convenient to use an editor that auto detects common mistakes (not unique for Python though).
Why do you need to reformat source files you download? Just follow the formatting conventions of the surrounding code and you'll save yourself a whole lot of headache. After all, style is but the most trivial of issues in programming, and the least relevant when it comes to getting the job done -- even if it's not your personal preference.
People who complain about Python's "whitespace thing" tend to be
people who write unreadable code in the first place; that's no
surprise.
Yes, I don't think it takes more time to get used to that than to get used to braces, but if you nest longer functions within functions it is possible to accidentally have a mis-indented ending. Not a frequent problem, though. Happens with braces too.
Once a piece of code grows past a certain length, and especially past a certain level of indentation, that's a hint that it's time to refactor. ;-) T -- In a world without fences, who needs Windows and Gates? -- Christian Surchi
Jan 22
parent Chris Wright <dhasenan gmail.com> writes:
On Fri, 22 Jan 2016 15:00:11 -0800, H. S. Teoh via Digitalmars-d wrote:

 On Fri, Jan 22, 2016 at 10:11:45PM +0000, Ola Fosheim Grøstad via
 Digitalmars-d wrote:
 On Friday, 22 January 2016 at 19:10:38 UTC, H. S. Teoh wrote:
I work with Python code without an IDE, and I manage just fine. As
long as you're consistent with how you use tabs vs. spaces, it's not a
problem.
Yes, if you use the same editor and reformat source files you download before editing them. I have found it to be more convenient to use an editor that auto detects common mistakes (not unique for Python though).
Why do you need to reformat source files you download? Just follow the formatting conventions of the surrounding code and you'll save yourself a whole lot of headache.
Because my text editor is set up with particular indentation settings and isn't good at autodetecting what's in use. Since this is a partially invisible aspect of formatting, it's safer to reformat files when I download them. I mean, sure, I can check manually when I start editing the file. And then I close the file for a moment to go back to the command line because I forgot to use tmux, and then I go back to the file, and since it's been half an hour I forgot about tabs versus spaces and now I'm introducing indentation errors again. Reformatting aggressively solves this problem.
Jan 22
prev sibling parent reply burjui <bytefu gmail.com> writes:
On Friday, 22 January 2016 at 18:28:31 UTC, Wyatt wrote:
 If you need an IDE to work comfortably in a language, something 
 has clearly gone wrong.
Oh come on, not that "Vim/Emacs vs IDEs" crap again. Please stop being so black&white and pretentious. Have you ever tried IntelliJ IDEA? It's the best IDE I know, and it saves me a lot of time by automating tasks I'm not interested in, e.g. reindenting the code, maintaining project files in Git, renaming things within their contexts etc., while proving an excellent debugger, a decent unit test runner and and integrated lint. I spend much less time messing with these things and have more time for actually writing the code and experimenting. If you consider all these conveniences unnecessary, good for you. You can continue using your favorite screwdriver, but most professionals prefer a screw gun, because it saves time. You may have big powerful hands, but you don't have to brag about it and point fingers: "Just look at this pussy with a screw gun, he clearly has never been to gym." By the way, it's perfectly normal to make screws that hold things tight, but not easily screwed in by hand.
Jan 25
next sibling parent reply Wyatt <wyatt.epp gmail.com> writes:
On Monday, 25 January 2016 at 18:34:24 UTC, burjui wrote:
 On Friday, 22 January 2016 at 18:28:31 UTC, Wyatt wrote:
 If you need an IDE to work comfortably in a language, 
 something has clearly gone wrong.
Oh come on, not that "Vim/Emacs vs IDEs" crap again. Please stop being so black&white and pretentious.
Begging your pardon? There's nothing wrong with an IDE; you clearly love yours -- love it to the point of spinning a single sentence into two paragraphs of inflammatory drivel casting me as a cave-dwelling primitive, even -- and that's great for you. But programming languages exist for people and their affordances come from this understanding, so I'm really not sure HOW you justify a language so poorly designed that it can't comfortably be used without an IDE. -Wyatt
Jan 25
parent reply w0rp <devw0rp gmail.com> writes:
I think we bicker and pontificate about these kinds of issues too 
much.

Do we want   for every attribute or not? If we haven't decided, 
we should decide.

If we do want   for everything, then create a pull request which 
does nothing but support   for all current attributes, in 
addition to the attributes without  . Don't worry about 
"attribute sets" and other wild ideas for now. Just tackle that 
one issue, otherwise no progress will be made. Attributes without 
  can become deprecation warnings, and can be removed later.

If you worry about the compiler becoming too complicated, I can 
assure you it will barely have an impact on compilation speed, 
and that's all users will care about.

If we don't want   for everything, then propose something else.

Sorry to be curt, but we've talked about this for long enough and 
gotten nowhere.
Jan 26
parent reply Wyatt <wyatt.epp gmail.com> writes:
On Tuesday, 26 January 2016 at 12:42:37 UTC, w0rp wrote:
 I think we bicker and pontificate about these kinds of issues 
 too much.
Yes. Sorry, got carried away on a tangent.
 Do we want   for every attribute or not?
Yes.
 If you worry about the compiler becoming too complicated, I can 
 assure you it will barely have an impact on compilation speed, 
 and that's all users will care about.
Was anyone even concerned about that? -Wyatt
Jan 26
parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Tuesday, 26 January 2016 at 13:16:10 UTC, Wyatt wrote:
 On Tuesday, 26 January 2016 at 12:42:37 UTC, w0rp wrote:
 Do we want   for every attribute or not?
Yes.
I'll agree. A number of the attributes that use won't be an option to use without the ; And having a half & half (or more like 1/3) better consistency and not having to remember special rules for which attributes use (and which don't) is one less thing I'd have to worry about. Although the could just be reserved for UDA's but that seems unlikely...
Jan 26
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Monday, 25 January 2016 at 18:34:24 UTC, burjui wrote:
 On Friday, 22 January 2016 at 18:28:31 UTC, Wyatt wrote:
 If you need an IDE to work comfortably in a language, 
 something has clearly gone wrong.
Oh come on, not that "Vim/Emacs vs IDEs" crap again.
Not what he was saying at all. He was making the point that languages which can't be comfortably used without an IDE must have something wrong in their design. He was making no judgements about IDEs vs. text editors.
Jan 26
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 22 January 2016 at 15:34:18 UTC, Wyatt wrote:
 "Contemporary". ;)
Well, contemporary in the sense that next generation of programmers are exposed to it and conditioned to it. So if you pick up the common syntactical structures from those languages it feels immediately natural to more people from the upcoming generation.
 Aside from Swift's optional semicolons, they're really not all 
 that different.
Here's one big difference that matters a lot for legibility: "name: type". Consistent usage of sigils matters a lot of both readability, autocompleting and error messages.
 Like Swift, C#, Javascript, Go, Haxe, Rust, Dart, et al?  
 Really, people have been predicting the death of curly-braces 
 languages for decades now, and they're as strong as ever.
Did I say anything about curly braces? A new language now should be designed with IDE autocompletion in mind and graphical oriented editing.
 Do you have anything to base this on, or is it just what you'd 
 (apparently) like to see?
What? I'm arguing if favour of sticking to what is emerging as the common idioms that lead to familiarity. Then I argue in favour of consistency, autocompletion-friendliness and higher levels of legibility. High levels of usability is very hard to achieve. One cannot arrive at excellent usability by adding and adding and adding... You need to redesign, test, evaluate, redesign, test, evaluate... etc.
Jan 22
prev sibling parent reply karabuta <karabutaworld gmail.com> writes:
On Friday, 22 January 2016 at 04:30:33 UTC, tsbockman wrote:
 On Friday, 22 January 2016 at 02:13:56 UTC, Ola Fosheim Grøstad 
 wrote:
 [...]
I don't necessarily disagree with your overall point, but I think the question of whether a few attributes have an attached to them or not ranks pretty low on the list of "70% solutions with marginal support" that need fixing/fleshing out. If this is truly among the most pressing issues with D, then D must be in great shape. It seems like poor allocation of resources (both those of the D development team, and those of the D users who would be forced to update their code) to put much effort into this right now, when there are so many other issues of greater practical import to work on.
Well, it's a big issue for me :)
Jan 23
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Saturday, 23 January 2016 at 20:07:48 UTC, karabuta wrote:
 On Friday, 22 January 2016 at 04:30:33 UTC, tsbockman wrote:
 I don't necessarily disagree with your overall point, but I 
 think the question of whether a few attributes have an   
 attached to them or not ranks pretty low on the list of "70% 
 solutions with marginal support" that need fixing/fleshing 
 out. If this is truly among the most pressing issues with D, 
 then D must be in great shape.

 [...]
Well, it's a big issue for me :)
Then I guess D must be in great shape :-D
Jan 23
parent karabuta <karabutaworld gmail.com> writes:
On Saturday, 23 January 2016 at 20:11:35 UTC, tsbockman wrote:
 On Saturday, 23 January 2016 at 20:07:48 UTC, karabuta wrote:
 On Friday, 22 January 2016 at 04:30:33 UTC, tsbockman wrote:
 I don't necessarily disagree with your overall point, but I 
 think the question of whether a few attributes have an   
 attached to them or not ranks pretty low on the list of "70% 
 solutions with marginal support" that need fixing/fleshing 
 out. If this is truly among the most pressing issues with D, 
 then D must be in great shape.

 [...]
Well, it's a big issue for me :)
Then I guess D must be in great shape :-D
And now they will argue about curly braces and semi-colons and the real issues for this thread will be forgotten and there will always be issues not resolved. People keep the hate in their heart and it leads to a whole lot of problem and heart and mental disease :) Seriously,
Jan 23
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, 21 January 2016 at 23:25:01 UTC, Era Scarecrow wrote:
 On Thursday, 21 January 2016 at 23:18:16 UTC, tsbockman wrote:
 Adding the   to the old attributes was discussed as well, but 
 it didn't seem worth the code breakage.
I have to wonder if it would be that bad, since if you're aware of where it breaks (which source code) wouldn't a bulk search/replace of the sources to resolve that?
It's never even been generally agreed upon that making it so that all attributes have on them is desirable, even if code breakage isn't taken into account. Do you want stuff like public, static, final, etc.? It gets ugly really fast, and it makes porting code from other languages gratuitously worse. Not using on any attributes would be far cleaner, but it would eat up more keywords, and we arguably have too many of those already. There really isn't a choice here that isn't ugly in some manner. So, even if we were starting from scratch, it's not clear what we would do. So, it's questionable that making a change would even really be an improvement, and if that's the case, it's definitely not worth the code breakage. And really, the worst that generally happens with what we have right now is that someone occasionally asks why some attributes start with and some don't. - Jonathan M Davis
Jan 22
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 22 January 2016 at 09:46:47 UTC, Jonathan M Davis 
wrote:
 Not using   on any attributes would be far cleaner, but it 
 would eat up more keywords, and we arguably have too many of 
 those already.
D is too complex to defend the position that you need _reserved_ keywords. Maybe at some point in the past D1 was simple enough to defend that position. You write a parser once or twice, so having a clean syntax weigh up for spending a little bit more time on the parser. What D needs is consistent usage of sigils. It makes code easier to read and easier to write. What does ":" mean? What does " " mean? What does "!" mean? No consistency in D.
Jan 22
parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 22 January 2016 at 13:30:40 UTC, Ola Fosheim Grøstad 
wrote:
 D is too complex to defend the position that you need 
 _reserved_ keywords. Maybe at some point in the past D1 was 
 simple enough to defend that position.

 You write a parser once or twice, so having a clean syntax 
 weigh up for spending a little bit more time on the parser.

 What D needs is consistent usage of sigils. It makes code 
 easier to read and easier to write.

 What does ":" mean? What does " " mean? What does "!" mean?

 No consistency in D.
I haven't had any difficulty with "!". It's not in some cases and for introducing template parameters in others. Never had much difficulty figuring out which is which. I had a little more difficulty with ":" in that its use in template specialization is different from inheritance. Now though I'm sort of used to it. Similarly, I'm used to . The only thing is that it's just so obviously inconsistent. It sticks out more than the others. Anyway, I found Dicebot's post about DIP64 convincing.
Jan 22
prev sibling next sibling parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Thursday, 21 January 2016 at 23:18:16 UTC, tsbockman wrote:
 A revision of D that wasn't constrained by backwards 
 compatibility would almost certainly either require all 
 attributes to be prefixed by  , or change the grammar such that 
 attribute names could be reused as identifier names without 
 introducing ambiguities.
It seems to me that ' ' could be allowed as optional prefix to attributes that currently don't have it without breaking code - or am I being naïve?
Jan 21
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, 22 January 2016 at 00:24:13 UTC, Dibyendu Majumdar 
wrote:
 On Thursday, 21 January 2016 at 23:18:16 UTC, tsbockman wrote:
 A revision of D that wasn't constrained by backwards 
 compatibility would almost certainly either require all 
 attributes to be prefixed by  , or change the grammar such 
 that attribute names could be reused as identifier names 
 without introducing ambiguities.
It seems to me that ' ' could be allowed as optional prefix to attributes that currently don't have it without breaking code - or am I being naïve?
Sure, but that complicates the compiler, it will probably marginally harm compilation times, and it will then result in some code using and some not for the same attribute - possibly even in the same codebase, which will just increase confusion to no real benefit. And we haven't even agreed that putting on attributes that don't currently have it is even desirable. So, if we decided that we definitely wanted on all attributes (or any particular set of attributes that don't currently have it), then we could do something like you suggest as a deprecation path and eventually make the required, but it really wouldn't make sense to leave it up to the programmer to decide which they want and just leave it that way, and we haven't decided that we want on all attributes anyway. - Jonathan M Davis
Jan 22
prev sibling parent Luis <luis.panadero gmail.com> writes:
On Thursday, 21 January 2016 at 23:18:16 UTC, tsbockman wrote:

 Adding the   to the old attributes was discussed as well, but 
 it didn't seem worth the code breakage.
And why not add the version of these attributes with and deprecate these attributes without for some time? So it allow to change it using tools like dfix.
Jan 22
prev sibling parent rsw0x <anonymous anonymous.com> writes:
On Thursday, 21 January 2016 at 23:05:51 UTC, Dibyendu Majumdar 
wrote:
 I am puzzled as to why there is  nogc on the one hand and 
 simply nothrow on the other? Why are some attributes prefixed 
 with ' ' while others aren't?

 Regards
"breakage" that could be fixed in a few minutes with grep meanwhile, I typically can't go a D version without actual breakage that takes hours to debug.
Jan 21