Re: Why do some attributes start with '@' while others done't?
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
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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...
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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 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
Re: Why do some attributes start with '@' while others done't?
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 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.
Re: Why do some attributes start with '@' while others done't?
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 :)
Re: Why do some attributes start with '@' while others done't?
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
Re: Why do some attributes start with '@' while others done't?
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, @
Re: Why do some attributes start with '@' while others done't?
On Fri, Jan 22, 2016 at 06:08:14PM +, 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
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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).
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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
Re: Why do some attributes start with '@' while others done't?
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
Re: Why do some attributes start with '@' while others done't?
On Fri, Jan 22, 2016 at 06:39:39PM +, 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.
Re: Why do some attributes start with '@' while others done't?
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
Re: Why do some attributes start with '@' while others done't?
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
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
On Fri, Jan 22, 2016 at 10:11:45PM +, 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
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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 +, 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.
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:48:03 UTC, Brian Schott wrote: Yeah. Somebody should write something like that. Wit. 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).
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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
Re: Why do some attributes start with '@' while others done't?
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. Wit. 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
Re: Why do some attributes start with '@' while others done't?
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.
Why do some attributes start with '@' while others done't?
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
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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
Re: Why do some attributes start with '@' while others done't?
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?
Re: Why do some attributes start with '@' while others done't?
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. Wit. 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.
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
On 01/22/2016 03:20 AM, Dicebot wrote: I'd definitely place something like `@safe` in type constructors @safe(int) ?
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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.)
Re: Why do some attributes start with '@' while others done't?
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.
Re: Why do some attributes start with '@' while others done't?
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?
