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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 

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 2016
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 

 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.



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


 [...]



 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 2016
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 2016
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 2016
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 Grøstad 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 2016
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 2016
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 2016
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 Grøstad 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 2016
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 2016
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 2016
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 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.  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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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.



 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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016