digitalmars.D - accept pure nothrow return attributes
- Paolo Invernizzi (5/5) Jan 26 2015 If someone is not following the merges, well... [1] !!
- Brian Schott (3/8) Jan 26 2015 I'm running out of ideas for DConf topics.
- Andrei Alexandrescu (4/14) Jan 26 2015 Heh, I infer that's a good thing. Nevertheless we should probably
- Meta (6/22) Jan 26 2015 The extra glyphs add a bit of visual noise, but I think that's
- Jonathan M Davis via Digitalmars-d (29/44) Jan 26 2015 In theory, the increased consistency is welcome, but the increased visua...
- bearophile (4/7) Jan 26 2015 So far I agree with Jonathan.
- Kenji Hara via Digitalmars-d (6/14) Jan 26 2015 Me too. At best it is just a cosmetic change, and will introduce huge co...
- Daniel Kozak (2/23) Jan 26 2015 Yes we should, it does not fix anything
- Francesco Cattoglio (7/25) Jan 26 2015 At this point, it might be nicer to have only attributes that
- Atila Neves (3/75) Jan 26 2015 +1
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (10/23) Jan 26 2015 I agree that you need to let "@" act as some kind of mnemonic
- Jonathan M Davis via Digitalmars-d (9/12) Jan 26 2015 All of the existing @ affect the type of the function. It's attributes l...
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (23/28) Jan 26 2015 I personally agree that it would be better to remove "@" like you
- Kenji Hara via Digitalmars-d (9/21) Jan 26 2015 Additional note: UDA can be attached to symbols only.
- Jonathan Marler (17/17) Jan 26 2015 I agree with Jonathan's points, this solution doesn't seem like
- Foo (4/21) Jan 26 2015 You could do the same as C++ with override and final: they are
- Walter Bright (8/11) Jan 26 2015 Just 'no' on context-sensitive tokens.
- Meta (2/15) Jan 26 2015 Some words are in high demand, however, like body and match.
- ketmar (12/28) Jan 26 2015 body will not be "dekeyworded".
- Jonathan Marler (23/36) Jan 26 2015 I'm not sure what you mean by "context-sensitive tokens". It
- Walter Bright (2/3) Jan 26 2015 A keyword in one context and an identifier in another.
- Jonathan Marler (9/12) Jan 26 2015 Then I'm a little confused. What does this have to do with
- Walter Bright (3/5) Jan 26 2015 The lexer has no idea what a function attribute is or that now it should...
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (4/9) Jan 26 2015 Not a problem, the parser can turn the token it back into a
- Jonathan Marler (16/22) Jan 26 2015 I feel like I keep repeating myself so I'm just going to
- Foo (3/27) Jan 26 2015 Right. That's was what I meant.
- Jonathan Marler (3/37) Jan 26 2015 Ya same thing applies to "body". I'm surprised no one has given
- Foo (7/46) Jan 26 2015 Because you/we are community members and therefore "second-class
- Walter Bright (3/6) Jan 26 2015 Major contributors to D, like Don Clugston, advocated for it.
- ketmar (3/11) Jan 26 2015 and repeatedly rejected. and then... wow! silently accepted. without=20
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (3/5) Jan 28 2015 I made a PR, but it was not too well-received:
- Walter Bright (5/14) Jan 26 2015 I strongly dislike context sensitive tokens, whether or not they are don...
- zeljkog (3/8) Jan 26 2015 I remember the first time I read about D was something like "make langua...
- Jonathan Marler (30/52) Jan 26 2015 Walter I hate to waste your time in answering my silly questions.
- Walter Bright (6/30) Jan 26 2015 Your argument boils down to there are no such things as token keywords. ...
- Jonathan Marler (23/76) Jan 26 2015 This has become quite frustrating. I'm not sure how else to
- ketmar (3/5) Jan 26 2015 you are dumb. you can be dumb for some time, and then BANG! your proposa...
- Jonathan Marler (16/24) Jan 27 2015 "that is the way of D"...sad... I may have to agree with you on
- ketmar (19/42) Jan 27 2015 you just have to write alot of unpleasant things, and then you'll be=20
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (22/28) Jan 27 2015 Isn't it more that one or two individuals don't get your point
- Jonathan Marler (4/32) Jan 27 2015 Interesting points. Thanks for the response, it's a relief to
- ketmar (2/4) Jan 27 2015 the funny thing is that Ola is a kind of "bad child" too. heh.=
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (22/27) Jan 27 2015 Hey, I have gray hairs in my beard! Show me sum respect, huh?
- ketmar (2/3) Jan 27 2015 me too!=
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (2/5) Jan 27 2015 Coolies! *smooch*
- Zach the Mystic (14/18) Jan 26 2015 How do you tell the difference between a return type and a user
- Jonathan Marler (23/44) Jan 26 2015 I wasn't proposing UDA's to omit the '@', only LDA's (Language
- Artur Skawina via Digitalmars-d (3/9) Jan 26 2015 C. C++. D. Windows. Pascal. System. exit. success. failure.
- Walter Bright (2/3) Jan 26 2015 They're never keywords.
- Artur Skawina via Digitalmars-d (8/13) Jan 26 2015 Hence, some other ones also don't really need to be keywords.
- Zach the Mystic (4/21) Jan 26 2015 I think the short answer is that it's WAY too complicated for the
- Jonathan Marler (17/42) Jan 26 2015 I wasn't saying that we should introduce ambiguity, I was saying
- Zach the Mystic (8/23) Jan 26 2015 I don't think it is possible. Any non-keyword identifier is
- Jonathan Marler (3/33) Jan 26 2015 The return type doesn't appear after the function signature.
- Zach the Mystic (17/23) Jan 26 2015 Yes it *is* another debate. Now you can't add attributes at the
- Jonathan Marler (6/33) Jan 26 2015 http://en.wikipedia.org/wiki/Straw_man
- Zach the Mystic (3/8) Jan 26 2015 Show code examples of how it would work. I can't guess anymore
- Jonathan Marler (19/29) Jan 26 2015 Haha, ok, sorry for being too abstract.
- Zach the Mystic (16/36) Jan 26 2015 Alright, good. However... I'm still against it. Firstly, in my
- Jonathan Marler (16/61) Jan 26 2015 I agree that the proposal doesn't solve the consistency issue,
- Zach the Mystic (14/32) Jan 26 2015 The consistency issue is precisely that there should not be more
- Jonathan Marler (28/64) Jan 26 2015 Yes you're right it adds more inconsistency (sorry what I said
- Zach the Mystic (12/25) Jan 26 2015 The third way is to do nothing, and live with the existing
- Jonathan Marler (22/47) Jan 26 2015 Yes doing nothing is the other option :) I'm kinda bummed we are
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (4/25) Jan 28 2015 The old syntax can be deprecated and removed after an appropriate
- Zach the Mystic (5/22) Jan 26 2015 Also, aren't attribute blocks made impossible by this?:
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (10/13) Jan 26 2015 There is no ambiguity in "object.body" or even "object.if =
- ZombineDev (6/20) Jan 26 2015 That's what pragma(mangle, "...")[1] is for. It is used at least
- ZombineDev (6/29) Jan 26 2015 Examples:
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (9/24) Jan 28 2015 I don't agree that it's complicated, it's just not the most
- Jacob Carlborg (5/19) Jan 26 2015 We could use compiler recognized UDA's. It's not complicated, at least
- Nick Treleaven (9/20) Jan 26 2015 Most of those also apply to variable members. pure, nothrow, return only...
- Nick Treleaven (3/4) Jan 26 2015 Actually inout can apply to local variables, so it shouldn't have a '@'
- Jonathan M Davis via Digitalmars-d (6/10) Jan 26 2015 You're right. I forgot about those two. But it's still the case that the
- Nick Treleaven (12/15) Jan 27 2015 But I explained that most function attributes don't only apply to
- Jonathan M Davis via Digitalmars-d (24/39) Jan 27 2015 abstract also applies to classes, as does final. Also, if we end up addi...
- Jonathan Marler (13/85) Jan 27 2015 I share your sentiments exactly. The only thing I would add is
- Nick Treleaven (7/13) Jan 27 2015 Yes, but they actually only affect the *functions* belonging to the
- Jonathan Marler (17/21) Jan 27 2015 I think you may have missed the point. I believe what Jonathan
- Nick Treleaven (5/24) Jan 27 2015 In that case I don't think you've really grokked my proposal. It only
- Jonathan Marler (20/59) Jan 27 2015 Problem Summary: Using an '@' symbol for some function attributes
- Kagamin (10/20) Jan 28 2015 Probably unimportant, but no, abstract and final apply to
- Jacob Carlborg (8/14) Jan 27 2015 We could change all attributes to be compiler recognized UDA's, which
- Daniel Kozak via Digitalmars-d (36/73) Jan 27 2015 Exactly I do not think we can (want to) be 100% consistent . Even If I
- Jonathan Marler (8/109) Jan 27 2015 Good idea. The only think I would change is when an attribute
- Nick Treleaven (5/7) Jan 26 2015 Being able to ignore things starting with @ is useful when reading
- Zach the Mystic (50/56) Jan 26 2015 I don't think this problem is solvable without "dfix". Here are
- Zach the Mystic (2/3) Jan 26 2015 s/5.5/B5
- Laeeth Isharc (11/11) Jan 26 2015 "5. The kind that a tool such as 'dfix', can automate. For
- Walter Bright (12/13) Jan 26 2015 It's good to have this discussion.
- H. S. Teoh via Digitalmars-d (14/34) Jan 26 2015 While I generally agree with the sentiment that this great debate over
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (3/44) Jan 28 2015 I wouldn't count `const` among functions annotations. It applies
- Dicebot (14/14) Jan 26 2015 It was sad that calls for more breakage were mostly ignored. But
- Walter Bright (2/7) Jan 26 2015 I can't find Don's original post on the topic.
- Paolo Invernizzi (7/18) Jan 26 2015 Donno If you are referring to this [1], but at least it's about
- Walter Bright (4/17) Jan 26 2015 Yup, that's it. Your search-foo is better than mine!
- Dicebot (11/18) Jan 26 2015 I was referring to earlier posts (as old as Don's dconf 2013 talk
- Walter Bright (3/10) Jan 26 2015 What I wanted by doing this is to produce some sort of consensus. The to...
- Jacob Carlborg (6/8) Jan 27 2015 You have complained that one of your old D1 projects didn't compile with...
- Walter Bright (2/5) Jan 27 2015 This change didn't break a single line in the libraries or the test suit...
- Dicebot (10/12) Jan 28 2015 Yes, but it didn't also fix anything, only introduced more ways
- bearophile (9/12) Jan 28 2015 One of the rules of the Python Zen:
- Dicebot (7/17) Jan 28 2015 I am aware of Python Zen and generally it is not applicable to D.
- Kagamin (3/4) Jan 28 2015 Fixes problems people have with inconsistent attribute syntax,
- Dicebot (12/16) Jan 28 2015 Yes, but as it has been already mentioned in this thread new
- Jonathan M Davis via Digitalmars-d (27/44) Jan 28 2015 Exactly. It's not like this is simply a discussion of whether a change w...
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (4/9) Jan 28 2015 The logical conclusion from that statement would be that D
- Jonathan M Davis via Digitalmars-d (28/37) Jan 28 2015 Not really. For instance, we could make the attributes "completely
- Jonathan Marler (11/47) Jan 28 2015 Actually we could support removing the '@' symbol from all
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (15/23) Jan 28 2015 I think I misinterpreted what you meant to say, but if the
- Jonathan M Davis via Digitalmars-d (29/52) Jan 28 2015 I don't see what any of that has to do with which attributes have @ on t...
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (25/45) Jan 28 2015 As I said, I misinterpreted what you wrote. You came through as
- Jonathan Marler (17/44) Jan 28 2015 I have proposed a way that I think is a win win. Add support for
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (6/12) Jan 28 2015 I agree. This would also be a nice way to introduce dfix. And
- Mike (4/5) Jan 28 2015 Then I recommend you submit a pull request.
- Jonathan Marler (12/17) Jan 28 2015 I would but Walter said no. I'm certain he misunderstood my
- Andrei Alexandrescu (4/25) Jan 28 2015 Was that the proposal leading to this state of affairs (quoting from
- Jonathan Marler (24/59) Jan 28 2015 You can follow this thread:
- Andrei Alexandrescu (6/60) Jan 28 2015 That's not a misunderstanding. Your proposal has been understood. It can...
- Jonathan Marler (17/24) Jan 28 2015 I don't have a problem with letting things go. What I have a
- Andrei Alexandrescu (10/33) Jan 28 2015 It may be the case you're using different definitions of the term
- Jonathan Marler (16/26) Jan 28 2015 Ok now we're getting somewhere. I guess the next thing I'd like
- Daniel Kozak via Digitalmars-d (14/38) Jan 28 2015 Thats not possible:
- Jonathan Marler (4/25) Jan 28 2015 None of those cases would valid. Non-Keyword attributes without
- Daniel Kozak via Digitalmars-d (2/39) Jan 28 2015 Typo I mean some_func
- Jonathan Marler (17/59) Jan 28 2015 Oh ok. Then I'm not sure what your trying to say with your
- Walter Bright (24/30) Jan 28 2015 Good language design has redundancy in it. Often people see the redundan...
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (10/15) Jan 28 2015 That explains why new languages make ";" optional, or wait...
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (4/19) Jan 29 2015 Counter example: Rust. Of course, Rust isn't the epitome of
- Nick Treleaven (4/6) Jan 29 2015 We're not going to significantly change the structural syntax of D, so
- FG (2/3) Jan 28 2015 I'm quite sure I have read this very same thing not so long ago. :)
- Andrei Alexandrescu (3/10) Jan 28 2015 We should add that stuff and what Jonathan wrote to the FAQ on the wiki....
- Walter Bright (8/15) Jan 28 2015 I repeat it regularly!
- Jacob Carlborg (5/9) Jan 29 2015 Ruby has implicit declaration of variables. Ruby it has been around
- deadalnix (4/14) Jan 29 2015 And it is so bad when the codebase grows that people are willing
- Paulo Pinto (2/18) Jan 29 2015 That is so yesterday, they are now either on Go or Clojure.
- Jacob Carlborg (4/6) Jan 29 2015 And still people are using it successfully.
- deadalnix (6/11) Jan 29 2015 Yes, my point is that there is tradeof.
- ketmar (4/17) Jan 29 2015 'cause they think that javascript is kind of magic that will turn their=...
- Walter Bright (8/15) Jan 29 2015 "Some languages have started out with the implicit declaration behavior,...
- Jonathan M Davis via Digitalmars-d (3/5) Jan 29 2015 C!
- Jacob Carlborg (6/7) Jan 30 2015 It works great, have you actually used it? The entire Rails plugin
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (7/12) Jan 30 2015 I have to agree with Jacob. It's an extremely powerful tool. It's
- Jacob Carlborg (8/16) Jan 29 2015 A good language design that doesn't require the ; statement terminator
- deadalnix (12/17) Jan 29 2015 Tells me what this function returns in javascript :
- ketmar (10/29) Jan 29 2015 this never worked good. see deadalnix. or:
- Jacob Carlborg (11/14) Jan 30 2015 In Ruby ".zed" is not valid code, so in Ruby it means:
- Walter Bright (6/22) Jan 29 2015 Oh, I know it can be made to work. That wasn't my point, which I shall r...
- Jacob Carlborg (12/16) Jan 30 2015 I never had problems with the error messages in Ruby. But I do have had
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (4/6) Jan 30 2015 I think Go actually injects ";" in the lexer on tokens that can
- Walter Bright (2/3) Jan 30 2015 Making it not an example of what I was talking about.
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (6/42) Jan 29 2015 Then I'm afraid the proposal is pointless :-( The goal AIUI is to
- Andrei Alexandrescu (13/35) Jan 28 2015 I'd say we just drop it. It's a waste of time to talk about it. There's
- Jonathan Marler (22/36) Jan 28 2015 Maybe this is a weak proposal but I don't know how to realize
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (4/7) Jan 28 2015 +1.000.000.000
- Dicebot (9/13) Jan 28 2015 I also think arguing is a very good way to learn too - but please
- Mike (10/12) Jan 28 2015 It would be nice to know the priorities of the leadership, but,
- Zach the Mystic (12/76) Jan 28 2015 I think a keyword is a keyword is a keyword. If it's a keyword to
- Jonathan Marler (17/27) Jan 28 2015 This is actually a valid argument against my proposal. Thank
- Zach the Mystic (9/34) Jan 28 2015 It's utterly confusing is the problem. I would consider it a
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (3/5) Jan 28 2015 @can @you @spot @the @contradiction @?
- Jonathan Marler (12/20) Jan 28 2015 I don't think this is confusing:
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (7/10) Jan 28 2015 Now you disappoint me. Your rebellious mindset has been poisoned
- Jonathan Marler (4/15) Jan 28 2015 Lol, you guys are hilarious. There's D1, D2 and now DOla and
- ketmar (2/18) Jan 28 2015 not "DKetmar", it's titled "Aliced". ;-)=
- Zach the Mystic (7/27) Jan 28 2015 I invested the time because you took a very polite and civil
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (28/31) Jan 29 2015 Indeed, Walter has some deep reasoning ENTIRELY based on personal
- ponce (13/39) Jan 29 2015 In the Mythical Man Month, Brooks advises for a single person
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (35/46) Jan 29 2015 You mean like Batman?
- Jacob Carlborg (5/7) Jan 29 2015 By that definition basically all declarations in the object module is a
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (11/13) Jan 28 2015 That's a reserved word. A reserved word cannot be used as an
- ketmar (9/12) Jan 28 2015 yep. that is "slave to the machine" approach. i don't really care how=20
- deadalnix (12/33) Jan 28 2015 That is a retarded mindset. It is not about how hard it is for
- ketmar (6/36) Jan 28 2015 and there are at least 4 available codebases for writing tools. for C++=...
- Brian Schott (11/32) Jan 28 2015 I take it you also don't care if your IDE lags for 5 seconds
- ketmar (15/44) Jan 28 2015 sure, i will not use such IDE, 'cause it's fubared. yet it has nothing=2...
- Brian Schott (3/10) Jan 28 2015 That's exactly right. I gave up on using dscanner and insisted on
- ketmar (3/12) Jan 28 2015 sorry, it wasn't obvious that i was talking not about you in personal, a...
- Andrei Alexandrescu (3/4) Jan 28 2015 Nice. Interrogative - time to promote dscanner to tools/? Brian, what do...
- Brian Schott (3/5) Jan 28 2015 That discussion probably deserves its own thread.
- weaselcat (3/45) Jan 28 2015 Uncalled for IMO, Schott's tools are great.
- ketmar (3/4) Jan 28 2015 sure. i wasn't talking about Brian in my text, that was my dumbiness tha...
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (17/25) Jan 29 2015 Actually, modern parsers can parse ambiguous grammars in O(N)
- Paolo Invernizzi (16/32) Jan 28 2015 I would love this, and I would be fine with the breakage costs,
- Kagamin (6/14) Jan 28 2015 Same for any symbol. Do you have a solution?
- Dicebot (10/21) Jan 28 2015 Long time ago I have proposed to actually define built-it
- Andrei Alexandrescu (2/4) Jan 28 2015 BTW what's the deal with std.meta? -- Andrei
- Dicebot (4/10) Jan 28 2015 I have replied today in relevant PR with few proposals. That one
- Andrei Alexandrescu (3/11) Jan 28 2015 Link: https://github.com/D-Programming-Language/phobos/pull/2687
- Kagamin (3/15) Jan 29 2015 I suppose, when UDA conflicts with builtin attribute, that UDA
- Jacob Carlborg (4/6) Jan 29 2015 We can always add another @ sign in front of new attributes ;)
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (8/11) Jan 28 2015 Yes... but which one is obvious:
- bearophile (7/12) Jan 28 2015 The first one (the list comp) is Pythonic, and it's obviously the
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (7/11) Jan 28 2015 Ok, so we agree, but I think the obvious way if we forget about
- zeljkog (3/8) Jan 28 2015 Yes but also:
- Andrei Alexandrescu (2/13) Jan 28 2015 Change has been reverted. -- Andrei
- Dicebot (10/11) Jan 28 2015 Thank you very much.
- Jonathan M Davis via Digitalmars-d (3/4) Jan 28 2015 Yay!
- Joseph Rushton Wakeling via Digitalmars-d (8/15) Jan 28 2015 I don't have any disagreement with your request for better reporting and...
- Dicebot (5/27) Jan 28 2015 I haven't said it is a breaking change on its own - but that
- Joseph Rushton Wakeling via Digitalmars-d (6/11) Jan 28 2015 Yea, you're right, this isn't about whether the feature is good or not
- deadalnix (2/17) Jan 26 2015 +1, and I doubt the ROI analysis will come positive.
- Zach the Mystic (2/6) Jan 26 2015 For my part, a 'dfix' solution is worth it. Anything else, not.
- bearophile (5/6) Jan 26 2015 Breaking the code should be justified by a worth gain. This patch
- Nick Treleaven (2/6) Jan 27 2015 It doesn't break code.
- Mike (37/56) Jan 26 2015 Not a deal-breaker for me, but I agree with the sentiment, and I
- uri (8/70) Jan 26 2015 +1 to all of this as it mirrors exactly how I feel about D at
- Walter Bright (2/5) Jan 26 2015 Half want breaking changes, the other half wants stability.
- Zach the Mystic (15/22) Jan 26 2015 I don't know if 'dfix' will be everything I hope it would be, but
- Walter Bright (3/5) Jan 26 2015 Inertia of people being reluctant to use it. It's still work for people ...
- Zach the Mystic (13/19) Jan 26 2015 What about compiler integration? I'm talking about fundamental
- Jonathan Marler (13/36) Jan 26 2015 This has come up before. I believe if was at DConf 2014 that
- Zach the Mystic (14/22) Jan 26 2015 It's only creepy if it doesn't work. And the compiler doesn't
- Jonathan Marler (4/27) Jan 26 2015 Not a bad idea. Maybe this will be less "creepy" to others :)
- Jacob Carlborg (5/16) Jan 27 2015 Seems overly complicated. How about the compiler just outputs new files
- Zach the Mystic (5/7) Jan 27 2015 The thing I care about is that the compiler leaves the user with
- Andrei Alexandrescu (11/30) Jan 26 2015 I'm ready to commit to dfix. Problem is many of the changes suggested
- uri (8/50) Jan 26 2015 Well said.
- Zach the Mystic (37/46) Jan 26 2015 I don't think there's any illusion about D's great progress. D
- Andrei Alexandrescu (2/5) Jan 26 2015 Fiddling with "@" is not important. -- Andrei
- Andrei Alexandrescu (6/7) Jan 26 2015 IMHO this is myopic. We have much larger issues with e.g. safety,
- Walter Bright (2/9) Jan 26 2015 I agree. Let's not get mired in an "illusion of progress".
- Mike (10/16) Jan 26 2015 Agreed, but...
- Andrei Alexandrescu (4/14) Jan 26 2015 I think they are.
- ketmar (7/13) Jan 27 2015 heh. i was very passionate about D, and i started the process of=20
- deadalnix (4/14) Jan 27 2015 A head of a 1000 employee software company would certainly have
- Paolo Invernizzi (5/20) Jan 27 2015 If I have interpreted this post in the correct way, this is a
- ketmar (12/22) Jan 27 2015 i don't know where you found that "1000" number, i was talking about=20
- Paolo Invernizzi (15/22) Jan 27 2015 I'm interested! I'm interested! ;-P
- ketmar (4/29) Jan 27 2015 i believe in D too, and i want it to succeed -- not only for me. that's=...
- Zach the Mystic (3/8) Jan 27 2015 Strategically, what has your outcast position gotten you? What
- ketmar (2/9) Jan 27 2015 i have an answer, but sorry, i prefer to not make it public.=
- Jacob Carlborg (6/18) Jan 27 2015 How is this change going to help when there's still a bunch of
- ketmar (4/27) Jan 27 2015 who cares? it's SLASHDOT USER! i doubt that he wrote anything except=20
- Nick Treleaven (3/6) Jan 27 2015 Those can apply to variables too. We could use built-in @attributes for
- Mike (5/7) Jan 26 2015 A trivial search and replace. Some might be against this change
- Walter Bright (2/8) Jan 26 2015 It's the continuous drip-drip-drip of this that ticks people off.
- Walter Bright (2/3) Jan 26 2015 I don't think there's any risk of bugzilla going down to zero by May :-)
- ketmar (4/4) Jan 26 2015 On Mon, 26 Jan 2015 09:29:40 +0000, Paolo Invernizzi wrote:
- Brian Schott (4/9) Jan 26 2015 In case anybody was wondering, dfix has had the ability to do the
If someone is not following the merges, well... [1] !! --- Paolo [1] http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171 hookshot-fe4-cp1-prd.iad.github.net.mail
Jan 26 2015
On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote:If someone is not following the merges, well... [1] !! --- Paolo [1] http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171 hookshot-fe4-cp1-prd.iad.github.net.mailI'm running out of ideas for DConf topics.
Jan 26 2015
On 1/26/15 1:50 AM, Brian Schott wrote:On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote:Heh, I infer that's a good thing. Nevertheless we should probably discuss this and its impact; don't forget we can always undo it before 2.067. Thoughts! -- AndreiIf someone is not following the merges, well... [1] !! --- Paolo [1] http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171 hookshot-fe4-cp1-prd.iad.github.net.mailI'm running out of ideas for DConf topics.
Jan 26 2015
On Monday, 26 January 2015 at 09:54:31 UTC, Andrei Alexandrescu wrote:On 1/26/15 1:50 AM, Brian Schott wrote:The extra glyphs add a bit of visual noise, but I think that's balanced out by the better consistency of the language and the growing sphere of functions which can have their attributes inferred.On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote:Heh, I infer that's a good thing. Nevertheless we should probably discuss this and its impact; don't forget we can always undo it before 2.067. Thoughts! -- AndreiIf someone is not following the merges, well... [1] !! --- Paolo [1] http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171 hookshot-fe4-cp1-prd.iad.github.net.mailI'm running out of ideas for DConf topics.
Jan 26 2015
On Monday, January 26, 2015 01:54:36 Andrei Alexandrescu via Digitalmars-d wrote:On 1/26/15 1:50 AM, Brian Schott wrote:In theory, the increased consistency is welcome, but the increased visual noise definitely is not. And if we leave in pure and nothrow without , then we're going to have code out there doing both, which adds to the confusion, and if we deprecate pure and nothrow without , then we'll be forced to change pretty much every D program in existence. But It's not like this really improves consistency all that much anyway, because public, protected, package, private, final, override, static, const, immutable, inout, and deprecated all don't have . So, most function attributes _don't_ have on them, and we just added to some of them, making things even _less_ consistent. In fact, priore to this, safe, trusted, system, and property were the _only_ function attributes with on them. So, if we really wanted to improve consistency IMHO, we'd get rid of from everything that's built-in and leave it for user-defined attributes, but that would break existing code too. Ultimately, I really don't see this as an improvement, because it really doesn't fix the consistency problem with attributes, and we're either going to have to change existing code or end up with both pure and pure, and nothrow and nothrow in the language, which is just ugly. But aside from having duplicate attributes for the same thing, I don't know that it really makes things any worse - though at least before this, we could just say that property, safe, trusted, and system were oddballs that were added late in the game and that they had , because we didn't want to add new keywords. With this change, I expect that it will be even less clear which attributes have on them and which don't. Personally, I'd much prefer that we not make this change. It's just shuffling things around in an attempt to make them more consistent while actually making them _less_ consistent. - Jonathan M DavisOn Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote:Heh, I infer that's a good thing. Nevertheless we should probably discuss this and its impact; don't forget we can always undo it before 2.067. Thoughts! -- AndreiIf someone is not following the merges, well... [1] !! --- Paolo [1] http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171 hookshot-fe4-cp1-prd.iad.github.net.mailI'm running out of ideas for DConf topics.
Jan 26 2015
Jonathan M Davis:Personally, I'd much prefer that we not make this change. It's just shuffling things around in an attempt to make them more consistent while actually making them _less_ consistent.So far I agree with Jonathan. Bye, bearophile
Jan 26 2015
2015-01-26 21:03 GMT+09:00 bearophile via Digitalmars-d < digitalmars-d puremagic.com>:Jonathan M Davis: Personally, I'd much prefer that we not make this change. It's justMe too. At best it is just a cosmetic change, and will introduce huge code style confusion. We should revert it quickly. Kenji Harashuffling things around in an attempt to make them more consistent while actually making them _less_ consistent.So far I agree with Jonathan. Bye, bearophile
Jan 26 2015
On Monday, 26 January 2015 at 13:57:13 UTC, Kenji Hara wrote:2015-01-26 21:03 GMT+09:00 bearophile via Digitalmars-d < digitalmars-d puremagic.com>:Yes we should, it does not fix anythingJonathan M Davis: Personally, I'd much prefer that we not make this change. It's justMe too. At best it is just a cosmetic change, and will introduce huge code style confusion. We should revert it quickly. Kenji Harashuffling things around in an attempt to make them more consistent while actually making them _less_ consistent.So far I agree with Jonathan. Bye, bearophile
Jan 26 2015
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote:But It's not like this really improves consistency all that much anyway, because public, protected, package, private, final, override, static, const, immutable, inout, and deprecated all don't have . So, most function attributes _don't_ have on them, and we just added to some of them, making things even _less_ consistent. In fact, priore to this, safe, trusted, system, and property were the _only_ function attributes with on them. So, if we really wanted to improve consistency IMHO, we'd get rid of from everything that's built-in and leave it for user-defined attributes, but that would break existing code too. - Jonathan M DavisAt this point, it might be nicer to have only attributes that exists as C++ keywords not having the identifier before them. That is: public, protected, private, override, deprecated, static and const. But this probably doesn't make much sense now, does it?
Jan 26 2015
+1 On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote:On Monday, January 26, 2015 01:54:36 Andrei Alexandrescu via Digitalmars-d wrote:On 1/26/15 1:50 AM, Brian Schott wrote:In theory, the increased consistency is welcome, but the increased visual noise definitely is not. And if we leave in pure and nothrow without , then we're going to have code out there doing both, which adds to the confusion, and if we deprecate pure and nothrow without , then we'll be forced to change pretty much every D program in existence. But It's not like this really improves consistency all that much anyway, because public, protected, package, private, final, override, static, const, immutable, inout, and deprecated all don't have . So, most function attributes _don't_ have on them, and we just added to some of them, making things even _less_ consistent. In fact, priore to this, safe, trusted, system, and property were the _only_ function attributes with on them. So, if we really wanted to improve consistency IMHO, we'd get rid of from everything that's built-in and leave it for user-defined attributes, but that would break existing code too. Ultimately, I really don't see this as an improvement, because it really doesn't fix the consistency problem with attributes, and we're either going to have to change existing code or end up with both pure and pure, and nothrow and nothrow in the language, which is just ugly. But aside from having duplicate attributes for the same thing, I don't know that it really makes things any worse - though at least before this, we could just say that property, safe, trusted, and system were oddballs that were added late in the game and that they had , because we didn't want to add new keywords. With this change, I expect that it will be even less clear which attributes have on them and which don't. Personally, I'd much prefer that we not make this change. It's just shuffling things around in an attempt to make them more consistent while actually making them _less_ consistent. - Jonathan M DavisOn Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote:Heh, I infer that's a good thing. Nevertheless we should probably discuss this and its impact; don't forget we can always undo it before 2.067. Thoughts! -- AndreiIf someone is not following the merges, well... [1] !! --- Paolo [1] http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171 hookshot-fe4-cp1-prd.iad.github.net.mailI'm running out of ideas for DConf topics.
Jan 26 2015
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote:immutable, inout, and deprecated all don't have . So, most function attributes _don't_ have on them, and we just added to some of them, making things even _less_ consistent. In fact, priore to this, safe, trusted, system, and property were the _only_ function attributes with on them. So, if we really wanted to improve consistency IMHO, we'd get rid of from everything that's built-in and leave it for user-defined attributes, but that would break existing code too.I agree that you need to let " " act as some kind of mnemonic and therefore assign meaning to it. One meaning would be to only use " " with attributes that do not affect computation, typing, overloading etc and use it only for safety-checks and optimization hints (like inlining). Besides it would be easy to change the parser so that terms can be reused as symbols if the grammar stays sound. I think that is true for most function attributes anyway.
Jan 26 2015
On Monday, January 26, 2015 13:21:54 via Digitalmars-d wrote:One meaning would be to only use " " with attributes that do not affect computation, typing, overloading etc and use it only for safety-checks and optimization hints (like inlining).All of the existing affect the type of the function. It's attributes like public or static which don't, and those still affect aspects of compilation and can easily cause compilation errors. There are not currently any attributes which are simply hints to the compiler, and the ones which affect the safety checks are _definitely_ part of the type of the function. So, I don't think that that particular distinction would work, even if we could freely rearrange which attributes had and which didn't. - Jonathan M Davis
Jan 26 2015
On Monday, 26 January 2015 at 15:07:24 UTC, Jonathan M Davis wrote:On Monday, January 26, 2015 13:21:54 via Digitalmars-d wrote: function. So, I don't think that that particular distinction would work, even if we could freely rearrange which attributes had and which didn't.I personally agree that it would be better to remove " " like you suggested and leave it for UDAs. Interpreting D code is hard for tools without a library anyway, so I think the current approach is unwarranted, and would rather see a more complicated grammar and parser in favour of usability. D could provide an official parser/semantic analysis library available for tools (like clang). The visual noise in D2 is too high IMO, and the reuse of keywords/symbols for unrelated functionality makes usability/legibility/reading comprehension worse. I think this alone is enough to prevent mainstream adoption. Other languages compensate by having constructs that allow you do use "keywords" for fieldnames in records. It is a better strategic move to favour good syntactical usability/legibility over parsing complexity. Clean context independent mapping between syntax and semantics is important. Besides, D really needs to allow the use of common nouns like "body" in structs (e.g. to implement the HTML DOM)... so a more wholesome approach to rethinking the D syntax would be welcome. The D syntax needs rethinking as a whole, not in bits and pieces. If you are gonna break, make it clean, and make the language easy to learn.
Jan 26 2015
2015-01-27 0:07 GMT+09:00 Jonathan M Davis via Digitalmars-d < digitalmars-d puremagic.com>:On Monday, January 26, 2015 13:21:54 via Digitalmars-d wrote:Additional note: UDA can be attached to symbols only. void foo() uda {} // __traits(getAttributes, foo) == (uda) // pragma(msg, typeof(foo)); prints void(), no uda void function() uda fp; // Error: user defined attributes cannot appear as postfixes Kenji HaraOne meaning would be to only use " " with attributes that do not affect computation, typing, overloading etc and use it only for safety-checks and optimization hints (like inlining).All of the existing affect the type of the function. It's attributes like public or static which don't, and those still affect aspects of compilation and can easily cause compilation errors. There are not currently any attributes which are simply hints to the compiler, and the ones which affect the safety checks are _definitely_ part of the type of the function. So, I don't think that that particular distinction would work, even if we could freely rearrange which attributes had and which didn't.
Jan 26 2015
I agree with Jonathan's points, this solution doesn't seem like an improvement. If I understand the problem, we don't want to make every attribute use the ' ' symbol because it looks bad and would cause a lot of code changes for sake of consistency. However, on the other hand, we don't want to support the new properties because we have to add them as keywords which would break code using those words and would make the language more restrictive (nothing can be named nogc/safe/...). Assuming I understand the problem, couldn't we modify the language grammar to support more attributes without making them keywords? Then we can omit the ' ' on future code (and fix the old code if we want) and we don't have to litter the language with new keywords. I understand that doing this may be fairly complicated. This may create some ambiguities in the grammar that would need to be handled carefully, but if it can work I think this would be a good option.
Jan 26 2015
On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler wrote:I agree with Jonathan's points, this solution doesn't seem like an improvement. If I understand the problem, we don't want to make every attribute use the ' ' symbol because it looks bad and would cause a lot of code changes for sake of consistency. However, on the other hand, we don't want to support the new properties because we have to add them as keywords which would break code using those words and would make the language more restrictive (nothing can be named nogc/safe/...). Assuming I understand the problem, couldn't we modify the language grammar to support more attributes without making them keywords? Then we can omit the ' ' on future code (and fix the old code if we want) and we don't have to litter the language with new keywords. I understand that doing this may be fairly complicated. This may create some ambiguities in the grammar that would need to be handled carefully, but if it can work I think this would be a good option.You could do the same as C++ with override and final: they are only valid attributes if they appear _after_ the function/method. Elsewhere they are still valid as identifiers for e.g. variables.
Jan 26 2015
On 1/26/2015 8:13 AM, Foo wrote:You could do the same as C++ with override and final: they are only valid attributes if they appear _after_ the function/method. Elsewhere they are still valid as identifiers for e.g. variables.Just 'no' on context-sensitive tokens. For context, TV vocabulary - 2,000 words High school vocabulary - 10,000 words College vocabulary - 30,000 words English - 1,000,000 words i.e. words are NOT a scarce resource (quite unlike punctuation).
Jan 26 2015
On Monday, 26 January 2015 at 19:44:18 UTC, Walter Bright wrote:On 1/26/2015 8:13 AM, Foo wrote:Some words are in high demand, however, like body and match.You could do the same as C++ with override and final: they are only valid attributes if they appear _after_ the function/method. Elsewhere they are still valid as identifiers for e.g. variables.Just 'no' on context-sensitive tokens. For context, TV vocabulary - 2,000 words High school vocabulary - 10,000 words College vocabulary - 30,000 words English - 1,000,000 words i.e. words are NOT a scarce resource (quite unlike punctuation).
Jan 26 2015
On Mon, 26 Jan 2015 19:46:21 +0000, Meta wrote:On Monday, 26 January 2015 at 19:44:18 UTC, Walter Bright wrote:body will not be "dekeyworded". Walter Bright 2014-02-12 14:44:20 UTC=20 In hindsight, the choice of 'body' for the keyword is unfortunate. But=20 fixing it would cause even worse problems, so I think we're stuck with it. nobody told us what "worse problems" are. using "body" is not confusing,=20 lowering it into identifier will not break any code, but... "worse=20 problems" awaits. i'm using patch that allows "body" as identifier for almost a year, i'm=20 constantly building alot of projects from dub repo, and i haven't=20 encountered any problems with it. but i believe that i'm simply doing=20 something wrong and dragons are around the corner.=On 1/26/2015 8:13 AM, Foo wrote:=20 Some words are in high demand, however, like body and match.You could do the same as C++ with override and final: they are only valid attributes if they appear _after_ the function/method. Elsewhere they are still valid as identifiers for e.g. variables.Just 'no' on context-sensitive tokens. For context, TV vocabulary - 2,000 words High school vocabulary - 10,000 words College vocabulary - 30,000 words English - 1,000,000 words i.e. words are NOT a scarce resource (quite unlike punctuation).
Jan 26 2015
On Monday, 26 January 2015 at 19:44:18 UTC, Walter Bright wrote:On 1/26/2015 8:13 AM, Foo wrote:I'm not sure what you mean by "context-sensitive tokens". It sounds like you might be saying that this requires the tokenizer to be context sensitive, but this isn't the case. Instead, allowing a function to be decorated with any number of "id" or "keyword" tokens would allow the language to add new attributes (without a ' ' character) by restricting the usage of attributes in the semantics instead of the syntax. void myfunc() foo bar safe nogc nothrow { } 'foo' and 'bar' don't break the syntax but are caught by the semantic analysis. Furthermore, I'm sure this type of thing is already done all over the place in the grammar. The following example comes to mind: struct St { } void main() { St St; } The "St" token is a decl type the first time and a variable name the second. I'm sure they are implemented as the same token but the grammar results in a different semantic meaning for both tokens.You could do the same as C++ with override and final: they are only valid attributes if they appear _after_ the function/method. Elsewhere they are still valid as identifiers for e.g. variables.Just 'no' on context-sensitive tokens. For context, TV vocabulary - 2,000 words High school vocabulary - 10,000 words College vocabulary - 30,000 words English - 1,000,000 words i.e. words are NOT a scarce resource (quite unlike punctuation).
Jan 26 2015
On 1/26/2015 12:34 PM, Jonathan Marler wrote:I'm not sure what you mean by "context-sensitive tokens".A keyword in one context and an identifier in another.
Jan 26 2015
On Monday, 26 January 2015 at 20:38:43 UTC, Walter Bright wrote:On 1/26/2015 12:34 PM, Jonathan Marler wrote:Then I'm a little confused. What does this have to do with adding new attributes to a function? Just because a word is used as a function attribute doesn't mean it has to be a keyword. If the grammar supported decorating a function with a list of id tokens (not just keywords), then you could implement a variation on the c++ solution of allowing "override" and "final" after a function signature. Just because they are function attributes does not mean they were tokenized as "keywords".I'm not sure what you mean by "context-sensitive tokens".A keyword in one context and an identifier in another.
Jan 26 2015
On 1/26/2015 12:45 PM, Jonathan Marler wrote:Just because they are function attributes does not mean they were tokenized as "keywords".The lexer has no idea what a function attribute is or that now it should be looking for attributes and then it should not be.
Jan 26 2015
On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote:On 1/26/2015 12:45 PM, Jonathan Marler wrote:Not a problem, the parser can turn the token it back into a string. All you need is a LUT. ( Besides, parser.c is screaming for a rewrite anyway... )Just because they are function attributes does not mean they were tokenized as "keywords".The lexer has no idea what a function attribute is or that now it should be looking for attributes and then it should not be.
Jan 26 2015
On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote:On 1/26/2015 12:45 PM, Jonathan Marler wrote:I feel like I keep repeating myself so I'm just going to copy/paste.Just because they are function attributes does not mean they were tokenized as "keywords".The lexer has no idea what a function attribute is or that now it should be looking for attributes and then it should not be.If the grammar supported decorating a function with a list of idtokens (not just keywords), then you could implement a variation on the c++ solution of allowing "override" and "final" after a function signature. The lexer would recognize these attributes as normal ID tokens. The grammar could be amended to allow a function to be decorated with keywords and generic id tokens. Then the meaning of those tokens would be handled by semantic analysis. So the result would be that the lexer would see "nogc" and "safe" as normal id tokens (not keywords) which would be consumed as function attributes by the grammar. As far as I can tell this results in the best of both worlds. We can omit the ' ' character on function attributes like safe and nogc but they don't have to be added as keywords.
Jan 26 2015
On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler wrote:On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote:Right. That's was what I meant. Same thing could be possible for body...On 1/26/2015 12:45 PM, Jonathan Marler wrote:I feel like I keep repeating myself so I'm just going to copy/paste.Just because they are function attributes does not mean they were tokenized as "keywords".The lexer has no idea what a function attribute is or that now it should be looking for attributes and then it should not be.If the grammar supported decorating a function with a list of idtokens (not just keywords), then you could implement a variation on the c++ solution of allowing "override" and "final" after a function signature. The lexer would recognize these attributes as normal ID tokens. The grammar could be amended to allow a function to be decorated with keywords and generic id tokens. Then the meaning of those tokens would be handled by semantic analysis. So the result would be that the lexer would see "nogc" and "safe" as normal id tokens (not keywords) which would be consumed as function attributes by the grammar. As far as I can tell this results in the best of both worlds. We can omit the ' ' character on function attributes like safe and nogc but they don't have to be added as keywords.
Jan 26 2015
On Monday, 26 January 2015 at 21:28:14 UTC, Foo wrote:On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler wrote:Ya same thing applies to "body". I'm surprised no one has given a reason why it wasn't done this way.On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote:Right. That's was what I meant. Same thing could be possible for body...On 1/26/2015 12:45 PM, Jonathan Marler wrote:I feel like I keep repeating myself so I'm just going to copy/paste.Just because they are function attributes does not mean they were tokenized as "keywords".The lexer has no idea what a function attribute is or that now it should be looking for attributes and then it should not be.If the grammar supported decorating a function with a list of idtokens (not just keywords), then you could implement a variation on the c++ solution of allowing "override" and "final" after a function signature. The lexer would recognize these attributes as normal ID tokens. The grammar could be amended to allow a function to be decorated with keywords and generic id tokens. Then the meaning of those tokens would be handled by semantic analysis. So the result would be that the lexer would see "nogc" and "safe" as normal id tokens (not keywords) which would be consumed as function attributes by the grammar. As far as I can tell this results in the best of both worlds. We can omit the ' ' character on function attributes like safe and nogc but they don't have to be added as keywords.
Jan 26 2015
On Monday, 26 January 2015 at 21:41:31 UTC, Jonathan Marler wrote:On Monday, 26 January 2015 at 21:28:14 UTC, Foo wrote:Because you/we are community members and therefore "second-class citizens". If we suggest or discuss something, it is not that important. But if a small reddit post is made, it matters more. Look what happend to auto ref for non templates: community wants it but we don't get it.On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler wrote:Ya same thing applies to "body". I'm surprised no one has given a reason why it wasn't done this way.On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote:Right. That's was what I meant. Same thing could be possible for body...On 1/26/2015 12:45 PM, Jonathan Marler wrote:I feel like I keep repeating myself so I'm just going to copy/paste.Just because they are function attributes does not mean they were tokenized as "keywords".The lexer has no idea what a function attribute is or that now it should be looking for attributes and then it should not be.If the grammar supported decorating a function with a list of idtokens (not just keywords), then you could implement a variation on the c++ solution of allowing "override" and "final" after a function signature. The lexer would recognize these attributes as normal ID tokens. The grammar could be amended to allow a function to be decorated with keywords and generic id tokens. Then the meaning of those tokens would be handled by semantic analysis. So the result would be that the lexer would see "nogc" and "safe" as normal id tokens (not keywords) which would be consumed as function attributes by the grammar. As far as I can tell this results in the best of both worlds. We can omit the ' ' character on function attributes like safe and nogc but they don't have to be added as keywords.
Jan 26 2015
On 1/26/2015 2:15 PM, Foo wrote:Because you/we are community members and therefore "second-class citizens". If we suggest or discuss something, it is not that important. But if a small reddit post is made, it matters more.Major contributors to D, like Don Clugston, advocated for it. It comes up repeatedly.
Jan 26 2015
On Mon, 26 Jan 2015 17:56:00 -0800, Walter Bright wrote:On 1/26/2015 2:15 PM, Foo wrote:and repeatedly rejected. and then... wow! silently accepted. without=20 discussion. D is not a community project. D is Walter Bright toy project.=Because you/we are community members and therefore "second-class citizens". If we suggest or discuss something, it is not that important. But if a small reddit post is made, it matters more.=20 Major contributors to D, like Don Clugston, advocated for it. =20 It comes up repeatedly.
Jan 26 2015
On Monday, 26 January 2015 at 21:41:31 UTC, Jonathan Marler wrote:Ya same thing applies to "body". I'm surprised no one has given a reason why it wasn't done this way.I made a PR, but it was not too well-received: https://github.com/D-Programming-Language/dmd/pull/3227
Jan 28 2015
On 1/26/2015 1:25 PM, Jonathan Marler wrote:The lexer would recognize these attributes as normal ID tokens. The grammar could be amended to allow a function to be decorated with keywords and generic id tokens. Then the meaning of those tokens would be handled by semantic analysis.Not going to do that.So the result would be that the lexer would see "nogc" and "safe" as normal id tokens (not keywords) which would be consumed as function attributes by the grammar. As far as I can tell this results in the best of both worlds. We can omit the ' ' character on function attributes like safe and nogc but they don't have to be added as keywords.I strongly dislike context sensitive tokens, whether or not they are done by the lexer or the parser or the semantic analysis. It's like using a nail for a cotter pin.
Jan 26 2015
On 26.01.15 23:08, Walter Bright wrote:I strongly dislike context sensitive tokens, whether or not they are done by the lexer or the parser or the semantic analysis. It's like using a nail for a cotter pin.I remember the first time I read about D was something like "make language easier for compiler". It attracted me. (OK not only this :)
Jan 26 2015
On Monday, 26 January 2015 at 22:09:44 UTC, Walter Bright wrote:On 1/26/2015 1:25 PM, Jonathan Marler wrote:Walter I hate to waste your time in answering my silly questions. I know you have a much deeper knowledge and understanding of the language then I. I can see that you believe my suggestion would create some unnecessary complexity ("It's like using a nail for a cotter pin"), however, I can't see how it would so I'm going to ask another question. I can see that you are trying to save time from your short responses so I'll understand if I understand if you feel I'm a lost cause and do not respond again. You said you strongly dislike "context-sensitive" tokens but I still don't know exactly what you mean by "context-sensitive". You said a token is "context-sensitive" if it is "A keyword in one context and an identifier in another". However, since I'm not proposing that "save" and "nogc" be keywords in any context, this doesn't appear to fall under your definition. So I must assume your real definition is more general. However, if the definition is too general then couldn't you consider almost any token "context-sensitive". For example, the token "static" or "ref" have different meanings depending on their context, so are they "context-sensitive"? Yes they are still keyword tokens, but "safe" and "nogc" would still just be regular id tokens so what makes "safe" and "nogc" more "context-sensitive" then "static" and "ref"? I'm honestly trying to understand. I can see from how the grammar works that you don't agree my solution is a good one, but I'm failing to understand why. I fail to see how allowing a function to be decorated with id tokens is more complex then only allowing keywords. Also sorry for harping on definitions, I majored in Computer Science and Mathematics...having strict definitions comes from my days of writing endless proofs.The lexer would recognize these attributes as normal ID tokens. The grammar could be amended to allow a function to be decorated with keywords and generic id tokens. Then the meaning of those tokens would be handled by semantic analysis.Not going to do that.So the result would be that the lexer would see "nogc" and "safe" as normal id tokens (not keywords) which would be consumed as function attributes by the grammar. As far as I can tell this results in the best of both worlds. We can omit the ' ' character on function attributes like safe and nogc but they don't have to be added as keywords.I strongly dislike context sensitive tokens, whether or not they are done by the lexer or the parser or the semantic analysis. It's like using a nail for a cotter pin.
Jan 26 2015
On 1/26/2015 3:07 PM, Jonathan Marler wrote:Walter I hate to waste your time in answering my silly questions. I know you have a much deeper knowledge and understanding of the language then I. I can see that you believe my suggestion would create some unnecessary complexity ("It's like using a nail for a cotter pin"), however, I can't see how it would so I'm going to ask another question. I can see that you are trying to save time from your short responses so I'll understand if I understand if you feel I'm a lost cause and do not respond again. You said you strongly dislike "context-sensitive" tokens but I still don't know exactly what you mean by "context-sensitive". You said a token is "context-sensitive" if it is "A keyword in one context and an identifier in another". However, since I'm not proposing that "save" and "nogc" be keywords in any context, this doesn't appear to fall under your definition. So I must assume your real definition is more general. However, if the definition is too general then couldn't you consider almost any token "context-sensitive". For example, the token "static" or "ref" have different meanings depending on their context, so are they "context-sensitive"? Yes they are still keyword tokens, but "safe" and "nogc" would still just be regular id tokens so what makes "safe" and "nogc" more "context-sensitive" then "static" and "ref"? I'm honestly trying to understand. I can see from how the grammar works that you don't agree my solution is a good one, but I'm failing to understand why. I fail to see how allowing a function to be decorated with id tokens is more complex then only allowing keywords. Also sorry for harping on definitions, I majored in Computer Science and Mathematics...having strict definitions comes from my days of writing endless proofs.Your argument boils down to there are no such things as token keywords. Yes, you can make a language work like that. I've seen it done. It is awful. The solution is clear: static is a keyword. You can NEVER use it as an identifier. Same with all other keywords.
Jan 26 2015
On Tuesday, 27 January 2015 at 01:55:30 UTC, Walter Bright wrote:On 1/26/2015 3:07 PM, Jonathan Marler wrote:This has become quite frustrating. I'm not sure how else to explain myself so maybe I'm just being dumb. Something inside me wants to explain myself again so I'll try one more time, if this fails, then it must be me not understanding your explanation and I'll give up. My proposal has nothing to do with keywords, it can be summarized with the following 2 steps: 1. Change the syntax of a function to allow it to be decorated with general id tokens. 2. Modify code generation to look at these new tokens and treat them as function attributes. I would suggest only allowing these id tokens to appear after the function arguments so as not to introduces any ambiguity in the grammar. void myfunc() pure safe nothrow nogc; pure (still a keyword, no change) safe (still NOT a keyword, no change) nothrow (stil a keyword, no change) nogc (still NOT a keyword, no change) My proposal is not trying making tokens "context-sensitive" by treating them as keywords sometimes and identifiers at other times. All it is doing is allowing an identifer token to be used as a function attribute. Nothing to do with keywords.Walter I hate to waste your time in answering my silly questions. I know you have a much deeper knowledge and understanding of the language then I. I can see that you believe my suggestion would create some unnecessary complexity ("It's like using a nail for a cotter pin"), however, I can't see how it would so I'm going to ask another question. I can see that you are trying to save time from your short responses so I'll understand if I understand if you feel I'm a lost cause and do not respond again. You said you strongly dislike "context-sensitive" tokens but I still don't know exactly what you mean by "context-sensitive". You said a token is "context-sensitive" if it is "A keyword in one context and an identifier in another". However, since I'm not proposing that "save" and "nogc" be keywords in any context, this doesn't appear to fall under your definition. So I must assume your real definition is more general. However, if the definition is too general then couldn't you consider almost any token "context-sensitive". For example, the token "static" or "ref" have different meanings depending on their context, so are they "context-sensitive"? Yes they are still keyword tokens, but "safe" and "nogc" would still just be regular id tokens so what makes "safe" and "nogc" more "context-sensitive" then "static" and "ref"? I'm honestly trying to understand. I can see from how the grammar works that you don't agree my solution is a good one, but I'm failing to understand why. I fail to see how allowing a function to be decorated with id tokens is more complex then only allowing keywords. Also sorry for harping on definitions, I majored in Computer Science and Mathematics...having strict definitions comes from my days of writing endless proofs.Your argument boils down to there are no such things as token keywords. Yes, you can make a language work like that. I've seen it done. It is awful. The solution is clear: static is a keyword. You can NEVER use it as an identifier. Same with all other keywords.
Jan 26 2015
On Tue, 27 Jan 2015 02:11:55 +0000, Jonathan Marler wrote:This has become quite frustrating. I'm not sure how else to explain myself so maybe I'm just being dumb.you are dumb. you can be dumb for some time, and then BANG! your proposal=20 is silently made "right". yet you're still dumb. that is The Way Of D.=
Jan 26 2015
On Tuesday, 27 January 2015 at 07:50:36 UTC, ketmar wrote:On Tue, 27 Jan 2015 02:11:55 +0000, Jonathan Marler wrote:"that is the way of D"...sad... I may have to agree with you on some of your points. Even after explaining my idea 3 or 4 times, it seemed to fall on deaf ears, or more specifically, uninterested ears that didn't try to understand. It's very frustrating when you take the time to write up an idea and no one bothers read it well enough to understand it, let alone take a few minutes to think about it. D is by far the best language I've worked with, but there's still work to be done. It has been quite disheartening when I try to discuss anything in the forums. People are very quick to respond to posts without fully reading them and the meat of the content gets lost in a slew of responses that miss the point. I'm not sure what I'm doing wrong or how this can be improved. But this pattern seems to keep happening no matter what topic is discussed. Not sure how to solve this...I'll think on this tomorrow.This has become quite frustrating. I'm not sure how else to explain myself so maybe I'm just being dumb.you are dumb. you can be dumb for some time, and then BANG! your proposal is silently made "right". yet you're still dumb. that is The Way Of D.
Jan 27 2015
On Tue, 27 Jan 2015 08:30:43 +0000, Jonathan Marler wrote:On Tuesday, 27 January 2015 at 07:50:36 UTC, ketmar wrote:you just have to write alot of unpleasant things, and then you'll be=20 twitted by the most of the readers. and then you'll get no feedback on=20 your posts at all, but that means that you'll not get a negative feedback=20 too. for me it's amusing to see how my rants becoming "the things". and i know=20 that i can write anything i want to, 'cause almost nobody is reading my=20 posts anyway. but for this particular issue... i'm enraged by the fact that it was=20 commited without discussion at all. my ER got some controversal=20 reactions, and i was believe that anything controversal is discussed=20 first, and only then it may be accepted. but it looks like Walter is=20 don't care about D users, the only thing he cares of is "will this be=20 usable for me?" yes, i know that this is a "personal attack". and i know that it's a=20 project of Walter after all, so he can do anything he want to. but D is=20 the best language i've seen and used, that's why i'm so passionate about=20 it (and rude alot of times, i know). my only excuse is that (as i told)=20 that almost nobody is reading my posts. ;-)=On Tue, 27 Jan 2015 02:11:55 +0000, Jonathan Marler wrote:=20 "that is the way of D"...sad... I may have to agree with you on some of your points. Even after explaining my idea 3 or 4 times, it seemed to fall on deaf ears, or more specifically, uninterested ears that didn't try to understand. It's very frustrating when you take the time to write up an idea and no one bothers read it well enough to understand it, let alone take a few minutes to think about it. D is by far the best language I've worked with, but there's still work to be done. It has been quite disheartening when I try to discuss anything in the forums. People are very quick to respond to posts without fully reading them and the meat of the content gets lost in a slew of responses that miss the point. I'm not sure what I'm doing wrong or how this can be improved. But this pattern seems to keep happening no matter what topic is discussed. Not sure how to solve this...I'll think on this tomorrow.This has become quite frustrating. I'm not sure how else to explain myself so maybe I'm just being dumb.you are dumb. you can be dumb for some time, and then BANG! your proposal is silently made "right". yet you're still dumb. that is The Way Of D.
Jan 27 2015
On Tuesday, 27 January 2015 at 08:30:46 UTC, Jonathan Marler wrote:People are very quick to respond to posts without fully reading them and the meat of the content gets lost in a slew of responses that miss the point. I'm not sure what I'm doing wrong or how this can be improved. But this pattern seems to keep happening no matter what topic is discussed. Not sure how to solve this...I'll think on this tomorrow.Isn't it more that one or two individuals don't get your point and keep arguing while the others got it? Anyway, the discussions on the rust dev list appears to be more educated than on the D forums, so maybe the people with a theoretical background gave up on D and was piqued by the potential given by linear typing? I think so... but they might get fed up with it eventually and in the mean time D has the opportunity to get the semantics right... From a political perspective it is better to leave the syntax as it is until the semantics of the language are frozen. If you keep changing the syntax then people will eventually be fed up with changes and it might be more difficult to push through a full redesign... Which in my opinion is needed. It is better to stay 25% flawed then eventually clean it up so that it is only 5% flawed, than to go from 25% bad to 20% bad to 15% and then people get fed up with changes and it is frozen at 15% flawed. The problem in the D community is that there is no planning. Syntax clean up should be a workgroup effort, not a metamorphic mutation process.
Jan 27 2015
On Tuesday, 27 January 2015 at 09:18:19 UTC, Ola Fosheim Grøstad wrote:On Tuesday, 27 January 2015 at 08:30:46 UTC, Jonathan Marler wrote:Interesting points. Thanks for the response, it's a relief to hear people making sense :)People are very quick to respond to posts without fully reading them and the meat of the content gets lost in a slew of responses that miss the point. I'm not sure what I'm doing wrong or how this can be improved. But this pattern seems to keep happening no matter what topic is discussed. Not sure how to solve this...I'll think on this tomorrow.Isn't it more that one or two individuals don't get your point and keep arguing while the others got it? Anyway, the discussions on the rust dev list appears to be more educated than on the D forums, so maybe the people with a theoretical background gave up on D and was piqued by the potential given by linear typing? I think so... but they might get fed up with it eventually and in the mean time D has the opportunity to get the semantics right... From a political perspective it is better to leave the syntax as it is until the semantics of the language are frozen. If you keep changing the syntax then people will eventually be fed up with changes and it might be more difficult to push through a full redesign... Which in my opinion is needed. It is better to stay 25% flawed then eventually clean it up so that it is only 5% flawed, than to go from 25% bad to 20% bad to 15% and then people get fed up with changes and it is frozen at 15% flawed. The problem in the D community is that there is no planning. Syntax clean up should be a workgroup effort, not a metamorphic mutation process.
Jan 27 2015
On Tue, 27 Jan 2015 10:21:52 +0000, Jonathan Marler wrote:Interesting points. Thanks for the response, it's a relief to hear people making sense :)the funny thing is that Ola is a kind of "bad child" too. heh.=
Jan 27 2015
On Tuesday, 27 January 2015 at 10:26:54 UTC, ketmar wrote:On Tue, 27 Jan 2015 10:21:52 +0000, Jonathan Marler wrote:Hey, I have gray hairs in my beard! Show me sum respect, huh? I was a silent D forum lurker for... 7 years or so, waiting for a mature C++ replacement. Then decided to jump in and push for more planning and GC free programming support. We have nogc now, which is good, but that is about it. A simple statement like "D syntax will be reworked in 2016, lets form a working group" and "we need to define goals for GC, let us form a working group" would go a long way. But that would mean giving up control. Which Andrei and Walter are not going to do, so that means capable people will keep sitting on the fence (who wants to waste their time to have their efforts vetoed?) What is unfortunate is that the D heads keep adding features faster then the old ones can be fixed... Recently STL compatibility became an official goal and C++ exceptions... I say no more than this: I cant think of a single C++ library I would link to that would require that. With an orderly executed plan and feature freeze D could be production ready in 2-3 years. With no plan... multiply by at least 3, so we have 6-9 more years to wait assuming the feature set now is frozen... Nice, I have to go back to C++ now... C ya.Interesting points. Thanks for the response, it's a relief to hear people making sense :)the funny thing is that Ola is a kind of "bad child" too. heh.
Jan 27 2015
On Tue, 27 Jan 2015 10:43:12 +0000, Ola Fosheim Gr=C3=B8stad wrote:Hey, I have gray hairs in my beard!me too!=
Jan 27 2015
On Tuesday, 27 January 2015 at 10:47:23 UTC, ketmar wrote:On Tue, 27 Jan 2015 10:43:12 +0000, Ola Fosheim Grøstad wrote:Coolies! *smooch*Hey, I have gray hairs in my beard!me too!
Jan 27 2015
On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler wrote:The lexer would recognize these attributes as normal ID tokens. The grammar could be amended to allow a function to be decorated with keywords and generic id tokens. Then the meaning of those tokens would be handled by semantic analysis.How do you tell the difference between a return type and a user attribute on the left side? nogc myUda1 myUda2 returnType funcName() { return returnType(a); } They are UDAs only because they are not the second-to-last id (the return type) or the last id (the function name). How do you do 'auto' inferred return types in this context, when the compiler thinks your UDA is also your return type? Also, why burden the *programmer* with having to sort this out? It's too ambiguous to read, for my taste. If I just switch the names the entire signature changes: nogc returnType myUda1 myUda2 funcName() { return returnType(a); } Now it's supposed to return a myUda2, just because you switched the ordering? I can see why this idea would be rejected.
Jan 26 2015
On Monday, 26 January 2015 at 23:41:07 UTC, Zach the Mystic wrote:On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler wrote:I wasn't proposing UDA's to omit the ' ', only LDA's (Language defined attributes). Also, again, your example is assuming that we allow identifiers before the function signature, which is on optional part of what I proposed. The bigger problem with that proposal would be that if a function can start with a list of general id tokens, it's very likely to create ambiguity in the grammar. However, if they can only appear after the function signature, I'm almost certain no ambiguity is created. There are different ways to get around this, one is to require the ' ' only if the attribute appears before the function signature. The other is to disallow function attributes before the signature (or at least certain ones). There's different solutions, but that's not the point of the proposal. The point of the proposal is to Allow a function to be decorated with id tokens (so long as it doesn't create ambiguity) in order to specify attribute like "safe"/"nogc"/etc There are different ways to implement this and I see people arguing about specific implementations, but no one is addressing the main concept of the proposal (except Walter who just says that he doesn't like "context-sensitive" tokens but I fail to see how this creates tokens that are more "context-sensitive" then other tokens)The lexer would recognize these attributes as normal ID tokens. The grammar could be amended to allow a function to be decorated with keywords and generic id tokens. Then the meaning of those tokens would be handled by semantic analysis.How do you tell the difference between a return type and a user attribute on the left side? nogc myUda1 myUda2 returnType funcName() { return returnType(a); } They are UDAs only because they are not the second-to-last id (the return type) or the last id (the function name). How do you do 'auto' inferred return types in this context, when the compiler thinks your UDA is also your return type? Also, why burden the *programmer* with having to sort this out? It's too ambiguous to read, for my taste. If I just switch the names the entire signature changes: nogc returnType myUda1 myUda2 funcName() { return returnType(a); } Now it's supposed to return a myUda2, just because you switched the ordering? I can see why this idea would be rejected.
Jan 26 2015
On 01/26/15 20:43, Walter Bright via Digitalmars-d wrote:On 1/26/2015 8:13 AM, Foo wrote:C. C++. D. Windows. Pascal. System. exit. success. failure. arturYou could do the same as C++ with override and final: they are only valid attributes if they appear _after_ the function/method. Elsewhere they are still valid as identifiers for e.g. variables.Just 'no' on context-sensitive tokens.
Jan 26 2015
On 1/26/2015 1:45 PM, Artur Skawina via Digitalmars-d wrote:C. C++. D. Windows. Pascal. System. exit. success. failure.They're never keywords.
Jan 26 2015
On 01/26/15 23:10, Walter Bright via Digitalmars-d wrote:On 1/26/2015 1:45 PM, Artur Skawina via Digitalmars-d wrote:Hence, some other ones also don't really need to be keywords. Note I'm not arguing for/against these changes; just pointing out that there's precedent, as context sensitive magic identifiers already exist in D. Whether you want to call them "tokens" doesn't really matter (it's just an implementation detail). I actually would have preferred that they don't exist, but they do. arturThey're never keywords.Just 'no' on context-sensitive tokens.C. C++. D. Windows. Pascal. System. exit. success. failure.
Jan 26 2015
On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler wrote:I agree with Jonathan's points, this solution doesn't seem like an improvement. If I understand the problem, we don't want to make every attribute use the ' ' symbol because it looks bad and would cause a lot of code changes for sake of consistency. However, on the other hand, we don't want to support the new properties because we have to add them as keywords which would break code using those words and would make the language more restrictive (nothing can be named nogc/safe/...). Assuming I understand the problem, couldn't we modify the language grammar to support more attributes without making them keywords? Then we can omit the ' ' on future code (and fix the old code if we want) and we don't have to litter the language with new keywords. I understand that doing this may be fairly complicated. This may create some ambiguities in the grammar that would need to be handled carefully, but if it can work I think this would be a good option.I think the short answer is that it's WAY too complicated for the benefit. Also, why burden the syntax highlighter, let alone the human reader, with ambiguities like this?
Jan 26 2015
On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic wrote:On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler wrote:I wasn't saying that we should introduce ambiguity, I was saying we should be careful not to introduce ambiguity. I wrote that to indicate that I wasn't sure if the solution would introduce ambiguity or not. Zach suggested a solution that I'm fairly certain would be unambiguous (it's nice to have c++ people who've already seen the same problem know of a solution). By restricting the attributes to only appear after a function signature, it would also normalize the issue of consistent location of attributes, but this is another debate. However, allowing the attributes to appear before the function signature *might* work, but that would require much more care and may not even be possible (like I said, I'm not sure). A comprimize could be to allow attributes to omit the ' ' character if they appear after the function signature and require the ' ' character if they appear before. I'm not saying that's a good idea, just an option.I agree with Jonathan's points, this solution doesn't seem like an improvement. If I understand the problem, we don't want to make every attribute use the ' ' symbol because it looks bad and would cause a lot of code changes for sake of consistency. However, on the other hand, we don't want to support the new properties because we have to add them as keywords which would break code using those words and would make the language more restrictive (nothing can be named nogc/safe/...). Assuming I understand the problem, couldn't we modify the language grammar to support more attributes without making them keywords? Then we can omit the ' ' on future code (and fix the old code if we want) and we don't have to litter the language with new keywords. I understand that doing this may be fairly complicated. This may create some ambiguities in the grammar that would need to be handled carefully, but if it can work I think this would be a good option.I think the short answer is that it's WAY too complicated for the benefit. Also, why burden the syntax highlighter, let alone the human reader, with ambiguities like this?
Jan 26 2015
On Monday, 26 January 2015 at 21:37:43 UTC, Jonathan Marler wrote:I think you meant someone else!I think the short answer is that it's WAY too complicated for the benefit. Also, why burden the syntax highlighter, let alone the human reader, with ambiguities like this?I wasn't saying that we should introduce ambiguity, I was saying we should be careful not to introduce ambiguity. I wrote that to indicate that I wasn't sure if the solution would introduce ambiguity or not. Zach suggested a solution that I'mfairly certain would be unambiguous (it's nice to have c++ people who've already seen the same problem know of a solution). By restricting the attributes to only appear after a function signature, it would also normalize the issue of consistent location of attributes, but this is another debate. However, allowing the attributes to appear before the function signature *might* work, but that would require much more care and may not even be possible (like I said, I'm not sure).I don't think it is possible. Any non-keyword identifier is assumed to be the return type of the function. It all has to be solved in the parsing phase. You can't wait till semantic analysis to figure out what's a return type and what's an attribute. This is why D compiles so fast, because all phases of compilation are distinct.
Jan 26 2015
On Monday, 26 January 2015 at 22:04:48 UTC, Zach the Mystic wrote:On Monday, 26 January 2015 at 21:37:43 UTC, Jonathan Marler wrote:Copy/Paste:I think you meant someone else!I think the short answer is that it's WAY too complicated for the benefit. Also, why burden the syntax highlighter, let alone the human reader, with ambiguities like this?I wasn't saying that we should introduce ambiguity, I was saying we should be careful not to introduce ambiguity. I wrote that to indicate that I wasn't sure if the solution would introduce ambiguity or not. Zach suggested a solution that I'mfairly certain would be unambiguous (it's nice to have c++ people who've already seen the same problem know of a solution). By restricting the attributes to only appear after a function signature, it would also normalize the issue of consistent location of attributes, but this is another debate. However, allowing the attributes to appear before the function signature *might* work, but that would require much more care and may not even be possible (like I said, I'm not sure).I don't think it is possible. Any non-keyword identifier is assumed to be the return type of the function. It all has to be solved in the parsing phase. You can't wait till semantic analysis to figure out what's a return type and what's an attribute. This is why D compiles so fast, because all phases of compilation are distinct.The return type doesn't appear after the function signature.solution). By restricting the attributes to only appear after a function signature, it would also normalize the issue of consistent location of attributes, but this is another debate.
Jan 26 2015
On Monday, 26 January 2015 at 23:32:59 UTC, Jonathan Marler wrote:Copy/Paste:Yes it *is* another debate. Now you can't add attributes at the beginning: // no can do anymore nogc pure myUda retType funcName() { ... } // must do this instead retType funcName() nogc pure myUdal { } You're suggesting canceling a whole style of labeling a function, aren't you? It's a big change. I wouldn't accept it unless it demonstrated a clear advantage. In fact, maybe it *can* demonstrate such, having all D functions be uniform in how their attributes are written, but you'll need a whole new thread and a DIP, and personally I don't see this carrying its weight.The return type doesn't appear after the function signature.solution). By restricting the attributes to only appear after a function signature, it would also normalize the issue of consistent location of attributes, but this is another debate.
Jan 26 2015
On Monday, 26 January 2015 at 23:50:12 UTC, Zach the Mystic wrote:On Monday, 26 January 2015 at 23:32:59 UTC, Jonathan Marler wrote:http://en.wikipedia.org/wiki/Straw_man I'm not proposing that we don't allow attributes before a function, I was mentioning an idea related to my proposal. I agree with everything you said, you're just not addressing the proposal itself (see the link).Copy/Paste:Yes it *is* another debate. Now you can't add attributes at the beginning: // no can do anymore nogc pure myUda retType funcName() { ... } // must do this instead retType funcName() nogc pure myUdal { } You're suggesting canceling a whole style of labeling a function, aren't you? It's a big change. I wouldn't accept it unless it demonstrated a clear advantage. In fact, maybe it *can* demonstrate such, having all D functions be uniform in how their attributes are written, but you'll need a whole new thread and a DIP, and personally I don't see this carrying its weight.The return type doesn't appear after the function signature.solution). By restricting the attributes to only appear after a function signature, it would also normalize the issue of consistent location of attributes, but this is another debate.
Jan 26 2015
On Monday, 26 January 2015 at 23:53:22 UTC, Jonathan Marler wrote:http://en.wikipedia.org/wiki/Straw_man I'm not proposing that we don't allow attributes before a function, I was mentioning an idea related to my proposal. I agree with everything you said, you're just not addressing the proposal itself (see the link).Show code examples of how it would work. I can't guess anymore what you're proposing.
Jan 26 2015
On Monday, 26 January 2015 at 23:55:55 UTC, Zach the Mystic wrote:On Monday, 26 January 2015 at 23:53:22 UTC, Jonathan Marler wrote:Haha, ok, sorry for being too abstract. I think a safe way to implement my proposal would be to do what c++ did and only allow non-keyword function attributes to omit the ' ' symbol if they appear after the function signature: Here's what would change ----------------------------------------------------------------- void myfunc() nogc; // VALID (Only if this proposal is accepted) void myfunc() safe; // VALID (Only if this proposal is accepted) Here's what WOULD NOT change ----------------------------------------------------------------- nogc myfunc(); // STILL INVALID: invalid unless it can be verified // that this wouldn't result in ambiguity // in the grammar void myfunc() nogc; // STILL VALID (no change) nogc myfunc(); // STILL VALID (no change) If the initial proposal is accepted by people, then we can talk about the other examples, but let's focus on the proposal before focusing on sub-proposals.http://en.wikipedia.org/wiki/Straw_man I'm not proposing that we don't allow attributes before a function, I was mentioning an idea related to my proposal. I agree with everything you said, you're just not addressing the proposal itself (see the link).Show code examples of how it would work. I can't guess anymore what you're proposing.
Jan 26 2015
On Tuesday, 27 January 2015 at 00:05:17 UTC, Jonathan Marler wrote:Haha, ok, sorry for being too abstract. I think a safe way to implement my proposal would be to do what c++ did and only allow non-keyword function attributes to omit the ' ' symbol if they appear after the function signature: Here's what would change ----------------------------------------------------------------- void myfunc() nogc; // VALID (Only if this proposal is accepted) void myfunc() safe; // VALID (Only if this proposal is accepted) Here's what WOULD NOT change ----------------------------------------------------------------- nogc myfunc(); // STILL INVALID: invalid unless it can be verified // that this wouldn't result in ambiguity // in the grammar void myfunc() nogc; // STILL VALID (no change) nogc myfunc(); // STILL VALID (no change) If the initial proposal is accepted by people, then we can talk about the other examples, but let's focus on the proposal before focusing on sub-proposals.Alright, good. However... I'm still against it. Firstly, in my first comment in the current thread, http://forum.dlang.org/post/uimpnhiweuitnnbeqshu forum.dlang.org ...I made a list of considerations, among which: 3. Singularity of usage also matters. There should only be one way to mark a given attribute, either with or without ` `. This alone puts me at next to zero for your proposal in terms of benefit. It will strike people as a strange and unnecessary exception to the way to mark their attributes, for the sake of a slight beautification of only those cases where the attributes come after the signature. Consider me an old-fashioned "a keyword is a keyword is a keyword" kind of guy. Yes, there are outliers (C++, D, exit, success, etc.), but I don't see why that list should be expanded, as it is nicely contained, IMO.
Jan 26 2015
On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic wrote:On Tuesday, 27 January 2015 at 00:05:17 UTC, Jonathan Marler wrote:I agree that the proposal doesn't solve the consistency issue, but the proposal doesn't make things more inconsistent then they already are. It adds another way to write these attributes, but it adds a way that makes more sense in my opinion. This is a step in the right direction in solving the problem. The next step would be to solve the consistency issue, but again, that's another debate. To conclude, which code would you rather write? void myfunc() pure safe nothrow nogc; void myfunc() pure safe nothrow nogc; This will inevitably result in someone writing this: pure safe nothrow nogc void myfunc(); which would still be invalid in this proposal, and I think this is still a problem but not a huge one since this is easily caught by the compiler.Haha, ok, sorry for being too abstract. I think a safe way to implement my proposal would be to do what c++ did and only allow non-keyword function attributes to omit the ' ' symbol if they appear after the function signature: Here's what would change ----------------------------------------------------------------- void myfunc() nogc; // VALID (Only if this proposal is accepted) void myfunc() safe; // VALID (Only if this proposal is accepted) Here's what WOULD NOT change ----------------------------------------------------------------- nogc myfunc(); // STILL INVALID: invalid unless it can be verified // that this wouldn't result in ambiguity // in the grammar void myfunc() nogc; // STILL VALID (no change) nogc myfunc(); // STILL VALID (no change) If the initial proposal is accepted by people, then we can talk about the other examples, but let's focus on the proposal before focusing on sub-proposals.Alright, good. However... I'm still against it. Firstly, in my first comment in the current thread, http://forum.dlang.org/post/uimpnhiweuitnnbeqshu forum.dlang.org ...I made a list of considerations, among which: 3. Singularity of usage also matters. There should only be one way to mark a given attribute, either with or without ` `. This alone puts me at next to zero for your proposal in terms of benefit. It will strike people as a strange and unnecessary exception to the way to mark their attributes, for the sake of a slight beautification of only those cases where the attributes come after the signature. Consider me an old-fashioned "a keyword is a keyword is a keyword" kind of guy. Yes, there are outliers (C++, D, exit, success, etc.), but I don't see why that list should be expanded, as it is nicely contained, IMO.
Jan 26 2015
On Tuesday, 27 January 2015 at 00:57:24 UTC, Jonathan Marler wrote:On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the MysticThe consistency issue is precisely that there should not be more than one way to write an attribute. Note that that's precisely where most of the opposition to this thread's original proposal came from. Uniformity means never having to explain to anybody why there is more than one way to do something. Both this thread's proposal and your proposal *introduce* inconsistency in this way.3. Singularity of usage also matters. There should only be one way to mark a given attribute, either with or without ` `.I agree that the proposal doesn't solve the consistency issue, but the proposal doesn't make things more inconsistent then they already are. It adds another way to write these attributes, but it adds a way that makes more sense in my opinion. This is a step in the right direction in solving the problem. The next step would be to solve the consistency issue, but again, that's another debate. To conclude, which code would you rather write?void myfunc() pure safe nothrow nogc; void myfunc() pure safe nothrow nogc; This will inevitably result in someone writing this: pure safe nothrow nogc void myfunc(); which would still be invalid in this proposal, and I think this is still a problem but not a huge one since this is easily caught by the compiler.This will annoy people even more than they are already annoyed by the ` `-on-some-attributes-and-not-others inconsistency. The latter type (type 2 in my first thread) already exists in the language, but it shoudln't be replaced by another type. This argument was already made by Jonathan Davis.
Jan 26 2015
On Tuesday, 27 January 2015 at 01:14:01 UTC, Zach the Mystic wrote:On Tuesday, 27 January 2015 at 00:57:24 UTC, Jonathan Marler wrote:Yes you're right it adds more inconsistency (sorry what I said was wrong). However, no matter what solution you choose you have to choose one of two evils. Either add inconsistency or break code. There's no way around it. If you ADD another way to write the attributes that looks better, you've created more "inconsistency". If you REPLACE the existing way to write attributes, you've now broken code. I proposed that we ADD another way of writing attributes, however, my proposal doesn't require that we ADD another way, instead, we can REPLACE the current way of writing attributes by normalizing where they appear. However, like I said, you have to choose one or the other, broken code or inconsistency. The nice part about ADDING another way of writing attributes is that the hope is that the inconsistency will be solved in the future. Changing the way to write attributes will introduce more inconsistency at first. However, the hope is that if the new way is "better" or looks "nicer", then developers will hopefully consistently choose the new way. Then, if there's no reason to keep the old way, it can be deprecated and the consistency issue is solved. So again, I was suggesting one way of implementing my proposal which was to add an inconsistency, but you could implement it another way but you would have to break code. Do you have a solution that doesn't do either? I think if you try to find one, you'll see that I'm right in saying you're going to have to choose one or the other.On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the MysticThe consistency issue is precisely that there should not be more than one way to write an attribute. Note that that's precisely where most of the opposition to this thread's original proposal came from. Uniformity means never having to explain to anybody why there is more than one way to do something. Both this thread's proposal and your proposal *introduce* inconsistency in this way.3. Singularity of usage also matters. There should only be one way to mark a given attribute, either with or without ` `.I agree that the proposal doesn't solve the consistency issue, but the proposal doesn't make things more inconsistent then they already are. It adds another way to write these attributes, but it adds a way that makes more sense in my opinion. This is a step in the right direction in solving the problem. The next step would be to solve the consistency issue, but again, that's another debate. To conclude, which code would you rather write?void myfunc() pure safe nothrow nogc; void myfunc() pure safe nothrow nogc; This will inevitably result in someone writing this: pure safe nothrow nogc void myfunc(); which would still be invalid in this proposal, and I think this is still a problem but not a huge one since this is easily caught by the compiler.This will annoy people even more than they are already annoyed by the ` `-on-some-attributes-and-not-others inconsistency. The latter type (type 2 in my first thread) already exists in the language, but it shoudln't be replaced by another type. This argument was already made by Jonathan Davis.
Jan 26 2015
On Tuesday, 27 January 2015 at 01:31:07 UTC, Jonathan Marler wrote:Yes you're right it adds more inconsistency (sorry what I said was wrong). However, no matter what solution you choose you have to choose one of two evils. Either add inconsistency or break code. There's no way around it. If you ADD another way to write the attributes that looks better, you've created more "inconsistency". If you REPLACE the existing way to write attributes, you've now broken code.The third way is to do nothing, and live with the existing inconsistency. It's not a bad choice, considering.So again, I was suggesting one way of implementing my proposal which was to add an inconsistency, but you could implement it another way but you would have to break code. Do you have a solution that doesn't do either? I think if you try to find one, you'll see that I'm right in saying you're going to have to choose one or the other.I already suggested the best solution I could come up with: break code in the most benign possible manner, using a compiler-integrated 'dfix' experience. BTW, I'm glad you agree with me about the ugliness of the sign. Even with dfix, the decision could still be made to have everything use 's, which would be a solution to the consistency problem, but I would only welcome it grudgingly. Good looking code is important to me, and is *not* where that's , so to say. :-)
Jan 26 2015
On Tuesday, 27 January 2015 at 02:30:12 UTC, Zach the Mystic wrote:On Tuesday, 27 January 2015 at 01:31:07 UTC, Jonathan Marler wrote:Yes doing nothing is the other option :) I'm kinda bummed we are in this situation in the first place. If we had a consistent design in the first place it would have saved all this trouble. Now we can: 1. Live with it 2. Break code 3. Create inconsistency I believe my proposal is how it should have been designed in the first place (allow identifiers to be function attributes), but not the only way to fix it is to choose 2 or 3. I don't like either option but I feel like the community is more accepting of option 3 with a deprecation of the old methods. The problem with doing nothing is these discussions are likely never going to end. Someone will always bring up this issue and people are going to waste time forever debating what should be done. Although I think it was you who suggested that we could simply document why it is the way it is, and that would help. Anyway, thanks for considering my proposal, I know you had to read a lot and you don't think it's a good idea but that's what these forums are for.Yes you're right it adds more inconsistency (sorry what I said was wrong). However, no matter what solution you choose you have to choose one of two evils. Either add inconsistency or break code. There's no way around it. If you ADD another way to write the attributes that looks better, you've created more "inconsistency". If you REPLACE the existing way to write attributes, you've now broken code.The third way is to do nothing, and live with the existing inconsistency. It's not a bad choice, considering.So again, I was suggesting one way of implementing my proposal which was to add an inconsistency, but you could implement it another way but you would have to break code. Do you have a solution that doesn't do either? I think if you try to find one, you'll see that I'm right in saying you're going to have to choose one or the other.I already suggested the best solution I could come up with: break code in the most benign possible manner, using a compiler-integrated 'dfix' experience. BTW, I'm glad you agree with me about the ugliness of the sign. Even with dfix, the decision could still be made to have everything use 's, which would be a solution to the consistency problem, but I would only welcome it grudgingly. Good looking code is important to me, and is *not* where that's , so to say. :-)
Jan 26 2015
On Tuesday, 27 January 2015 at 01:14:01 UTC, Zach the Mystic wrote:On Tuesday, 27 January 2015 at 00:57:24 UTC, Jonathan Marler wrote:The old syntax can be deprecated and removed after an appropriate period.On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the MysticThe consistency issue is precisely that there should not be more than one way to write an attribute. Note that that's precisely where most of the opposition to this thread's original proposal came from. Uniformity means never having to explain to anybody why there is more than one way to do something. Both this thread's proposal and your proposal *introduce* inconsistency in this way.3. Singularity of usage also matters. There should only be one way to mark a given attribute, either with or without ` `.I agree that the proposal doesn't solve the consistency issue, but the proposal doesn't make things more inconsistent then they already are. It adds another way to write these attributes, but it adds a way that makes more sense in my opinion. This is a step in the right direction in solving the problem. The next step would be to solve the consistency issue, but again, that's another debate. To conclude, which code would you rather write?
Jan 28 2015
On Monday, 26 January 2015 at 23:50:12 UTC, Zach the Mystic wrote:Yes it *is* another debate. Now you can't add attributes at the beginning: // no can do anymore nogc pure myUda retType funcName() { ... } // must do this instead retType funcName() nogc pure myUdal { } You're suggesting canceling a whole style of labeling a function, aren't you? It's a big change. I wouldn't accept it unless it demonstrated a clear advantage. In fact, maybe it *can* demonstrate such, having all D functions be uniform in how their attributes are written, but you'll need a whole new thread and a DIP, and personally I don't see this carrying its weight.Also, aren't attribute blocks made impossible by this?: nogc: auto myFunc() { ... } auto myOtherFunc() { ... }
Jan 26 2015
On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic wrote:I think the short answer is that it's WAY too complicated for the benefit. Also, why burden the syntax highlighter, let alone the human reader, with ambiguities like this?There is no ambiguity in "object.body" or even "object.if = 42"... All you need is an escape mechanism in the definition. The reason for why you want this is that you interoperate with external interfacing definitions and standards that you auto generate D code from. It is not likely that the external world (like governments who define record exchange standards) will adapt their naming policies to D idiocracies. If you cannot use "body" as a field name then you cannot implement the HTML5 DOM according to the standard.
Jan 26 2015
That's what pragma(mangle, "...")[1] is for. It is used at least a couple of times in druntime (and probably elsewhere - e.g. in library bindings). [1]: http://dlang.org/pragma.html (at the bottom of the page) On Monday, 26 January 2015 at 21:56:20 UTC, Ola Fosheim Grøstad wrote:On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic wrote:I think the short answer is that it's WAY too complicated for the benefit. Also, why burden the syntax highlighter, let alone the human reader, with ambiguities like this?There is no ambiguity in "object.body" or even "object.if = 42"... All you need is an escape mechanism in the definition. The reason for why you want this is that you interoperate with external interfacing definitions and standards that you auto generate D code from. It is not likely that the external world (like governments who define record exchange standards) will adapt their naming policies to D idiocracies. If you cannot use "body" as a field name then you cannot implement the HTML5 DOM according to the standard.
Jan 26 2015
Examples: [1]: https://github.com/D-Programming-Language/druntime/blob/2024ca6d3e29362a2fc84ef51c0f73316259d645/src/core/internal/traits.d#L57 [2]: https://github.com/D-Programming-Language/phobos/blob/de5d3392782c85e79e71e257b3ba607ccff852a5/std/typecons.d#L3240 On Monday, 26 January 2015 at 22:02:44 UTC, ZombineDev wrote:That's what pragma(mangle, "...")[1] is for. It is used at least a couple of times in druntime (and probably elsewhere - e.g. in library bindings). [1]: http://dlang.org/pragma.html (at the bottom of the page) On Monday, 26 January 2015 at 21:56:20 UTC, Ola Fosheim Grøstad wrote:On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic wrote:I think the short answer is that it's WAY too complicated for the benefit. Also, why burden the syntax highlighter, let alone the human reader, with ambiguities like this?There is no ambiguity in "object.body" or even "object.if = 42"... All you need is an escape mechanism in the definition. The reason for why you want this is that you interoperate with external interfacing definitions and standards that you auto generate D code from. It is not likely that the external world (like governments who define record exchange standards) will adapt their naming policies to D idiocracies. If you cannot use "body" as a field name then you cannot implement the HTML5 DOM according to the standard.
Jan 26 2015
On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic wrote:On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler wrote:I don't agree that it's complicated, it's just not the most beautiful thing. But it is already used in several places. As for the syntax highlighters, any identifiers between `)` and `{`, or `)` and `;` can be treated as function attributes, except those that are already known to be keywords. No problem there. And for human readers it would be even easier, because now all function attributes have to be placed on the right side of the declaration.Assuming I understand the problem, couldn't we modify the language grammar to support more attributes without making them keywords? Then we can omit the ' ' on future code (and fix the old code if we want) and we don't have to litter the language with new keywords. I understand that doing this may be fairly complicated. This may create some ambiguities in the grammar that would need to be handled carefully, but if it can work I think this would be a good option.I think the short answer is that it's WAY too complicated for the benefit. Also, why burden the syntax highlighter, let alone the human reader, with ambiguities like this?
Jan 28 2015
On 2015-01-26 17:10, Jonathan Marler wrote:I agree with Jonathan's points, this solution doesn't seem like an improvement. If I understand the problem, we don't want to make every attribute use the ' ' symbol because it looks bad and would cause a lot of code changes for sake of consistency. However, on the other hand, we don't want to support the new properties because we have to add them as keywords which would break code using those words and would make the language more restrictive (nothing can be named nogc/safe/...). Assuming I understand the problem, couldn't we modify the language grammar to support more attributes without making them keywords? Then we can omit the ' ' on future code (and fix the old code if we want) and we don't have to litter the language with new keywords. I understand that doing this may be fairly complicated. This may create some ambiguities in the grammar that would need to be handled carefully, but if it can work I think this would be a good option.We could use compiler recognized UDA's. It's not complicated, at least no in the case I've implemented it. -- /Jacob Carlborg
Jan 26 2015
On 26/01/2015 11:39, Jonathan M Davis via Digitalmars-d wrote:In theory, the increased consistency is welcome, but the increased visual noise definitely is not. And if we leave in pure and nothrow without , then we're going to have code out there doing both, which adds to the confusion, and if we deprecate pure and nothrow without , then we'll be forced to change pretty much every D program in existence.Only if the deprecation became an error.But It's not like this really improves consistency all that much anyway, because public, protected, package, private, final, override, static, const, immutable, inout, and deprecated all don't have .Most of those also apply to variable members. pure, nothrow, return only apply to functions. I like this change, but it might be better if final, override and inout gained attribute syntax too. Then it would have more consistency. Also the inverted-attribute option then doesn't need !ugly !sigils - impure vs pure, throw vs nothrow, etc.In fact, priore to this, safe, trusted, system, and property were the_only_ function attributes with on them.There's also disable and more recently, nogc.
Jan 26 2015
On 26/01/2015 17:07, Nick Treleaven wrote:and inout gained attribute syntax tooActually inout can apply to local variables, so it shouldn't have a ' ' by my logic.
Jan 26 2015
On Mon, 26 Jan 2015 17:07:26 +0000 Nick Treleaven via Digitalmars-d <digitalmars-d puremagic.com> wrote:You're right. I forgot about those two. But it's still the case that the number of function attributes that don't have on them is _far_ greater than the number of those that do. - Jonathan M DavisIn fact, priore to this, safe, trusted, system, and property were the_only_ function attributes with on them.There's also disable and more recently, nogc.
Jan 26 2015
On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote:You're right. I forgot about those two. But it's still the case that the number of function attributes that don't have on them is_far_ greater than the number of those that do.But I explained that most function attributes don't only apply to functions but to variables as well: public, protected, package, private, static, const, immutable, inout, and deprecated So it can be consistent that the above don't use . These only affect functions, not variables, so should be attributes IMO: final, override, abstract These affect both: return, ref So if we want some kind of consistency, we can achieve it by adding for final, override, abstract, and removing it for 'return'.
Jan 27 2015
On Tuesday, January 27, 2015 11:47:04 Nick Treleaven via Digitalmars-d wrote:On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote:abstract also applies to classes, as does final. Also, if we end up adding any new attributes later, they're bound to have on them to avoid requiring a keyword (which is why we have on some of them in the first place), and if the new attribute applies to variables or types as well, then the division that you're suggesting falls apart. IMHO, if we have to search for a way to make them consistent, then there's no point. We're just going to end up with making things more consistent in one way and less in another without necessarily making it any easier for anyone to keep track of, so we'd just be shuffling things around. I think that there needs to be a clear and solid benefit to changing which attributes have and which don't, or we shouldn't mess with them. Honestly, I just consider to be part of the name, and I memorized it as part of the keyword. The result is that I don't even remember ever having a problem trying to figure out which attributes had and which didn't. Sure, it would be nice we had a rule of thumb that we could give newbies that would tell them which to use, but so few have that I really don't think that it's much of a practical issue - just an aesthetic one. I'd also point out that the compiler will give an error message telling you which attributes have on them you use something like deprecated, so it's not hard at all to figure out what you did wrong. So, even if someone has trouble remembering which built-in attributes start with , they'll figure out where they got it wrong quite quickly. - Jonathan M DavisYou're right. I forgot about those two. But it's still the case that the number of function attributes that don't have on them is_far_ greater than the number of those that do.But I explained that most function attributes don't only apply to functions but to variables as well: public, protected, package, private, static, const, immutable, inout, and deprecated So it can be consistent that the above don't use . These only affect functions, not variables, so should be attributes IMO: final, override, abstract These affect both: return, ref So if we want some kind of consistency, we can achieve it by adding for final, override, abstract, and removing it for 'return'.
Jan 27 2015
On Tuesday, 27 January 2015 at 16:50:00 UTC, Jonathan M Davis wrote:On Tuesday, January 27, 2015 11:47:04 Nick Treleaven via Digitalmars-d wrote:I share your sentiments exactly. The only thing I would add is that I don't see why we can't just remove the ' ' symbol from all language defined function attributes. I've already proposed a way to do this that wouldn't add any more keywords and would be fairly trivial to do (see my previous posts). However, since Walter doesn't like my idea I guess it's dead. However, I can't figure out why he doesn't like it...so. This issue isn't a huge deal, like you said it's not too hard to learn which ones require the ' ' symbol and which ones don't, it just looks weird. It's just too bad that my solution isn't even considered even though it would solve all these issues.On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote:abstract also applies to classes, as does final. Also, if we end up adding any new attributes later, they're bound to have on them to avoid requiring a keyword (which is why we have on some of them in the first place), and if the new attribute applies to variables or types as well, then the division that you're suggesting falls apart. IMHO, if we have to search for a way to make them consistent, then there's no point. We're just going to end up with making things more consistent in one way and less in another without necessarily making it any easier for anyone to keep track of, so we'd just be shuffling things around. I think that there needs to be a clear and solid benefit to changing which attributes have and which don't, or we shouldn't mess with them. Honestly, I just consider to be part of the name, and I memorized it as part of the keyword. The result is that I don't even remember ever having a problem trying to figure out which attributes had and which didn't. Sure, it would be nice we had a rule of thumb that we could give newbies that would tell them which to use, but so few have that I really don't think that it's much of a practical issue - just an aesthetic one. I'd also point out that the compiler will give an error message telling you which attributes have on them you use something like deprecated, so it's not hard at all to figure out what you did wrong. So, even if someone has trouble remembering which built-in attributes start with , they'll figure out where they got it wrong quite quickly. - Jonathan M DavisYou're right. I forgot about those two. But it's still the case that the number of function attributes that don't have on them is_far_ greater than the number of those that do.But I explained that most function attributes don't only apply to functions but to variables as well: public, protected, package, private, static, const, immutable, inout, and deprecated So it can be consistent that the above don't use . These only affect functions, not variables, so should be attributes IMO: final, override, abstract These affect both: return, ref So if we want some kind of consistency, we can achieve it by adding for final, override, abstract, and removing it for 'return'.
Jan 27 2015
On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote:abstract also applies to classes, as does final.Yes, but they actually only affect the *functions* belonging to the class, not the variables. A class is not a variable.Also, if we end up adding any new attributes later, they're bound to have on them to avoid requiring a keyword (which is why we have on some of them in the first place), and if the new attribute applies to variables or types as well, then the division that you're suggesting falls apart.It's inspired from the status quo - there are no attributes that apply to variables. __gshared uses underscores instead of attribute syntax. If we want to introduce a new attribute that applies to both functions and variables, use __attribute.
Jan 27 2015
On Tuesday, 27 January 2015 at 17:18:11 UTC, Nick Treleaven wrote:On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote:I think you may have missed the point. I believe what Jonathan is saying is that if you turn abstract into abstract then you have to consider how to solve the "abstract class" issue. Do you change it to: abstract class ? Same thing with final. Since the same keywords are used in a lot of different contexts, if you change how it is used in one context then it's going to be inconsistent with how it's used in the other contexts (like with a function or a class). Then if you want consistency (which is the point of why we are discussing this change in the first place) you have to change every context it is used in. If you follow through with your proposal, you'll end up putting a ' ' character before almost every keyword in the language which has no benefit since the ' ' symbol serves no useful purpose to the compiler in the first place (on a keyword at least).abstract also applies to classes, as does final.Yes, but they actually only affect the *functions* belonging to the class, not the variables. A class is not a variable.
Jan 27 2015
On 27/01/2015 18:01, Jonathan Marler wrote:On Tuesday, 27 January 2015 at 17:18:11 UTC, Nick Treleaven wrote:Yes, because it affects the class's functions, not its variable members.On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote:I think you may have missed the point. I believe what Jonathan is saying is that if you turn abstract into abstract then you have to consider how to solve the "abstract class" issue. Do you change it to: abstract class ?abstract also applies to classes, as does final.Yes, but they actually only affect the *functions* belonging to the class, not the variables. A class is not a variable.Same thing with final. Since the same keywords are used in a lot of different contexts, if you change how it is used in one context then it's going to be inconsistent with how it's used in the other contexts (like with a function or a class). Then if you want consistency (which is the point of why we are discussing this change in the first place) you have to change every context it is used in. If you follow through with your proposal, you'll end up putting a ' ' character before almost every keyword in the languageIn that case I don't think you've really grokked my proposal. It only requires 5 changes to attributes for consistency (and that's counting pure and nothrow).
Jan 27 2015
On Tuesday, 27 January 2015 at 18:21:37 UTC, Nick Treleaven wrote:On 27/01/2015 18:01, Jonathan Marler wrote:Problem Summary: Using an ' ' symbol for some function attributes and not others is weird. void foo() pure safe const; Current Reason: keywords don't use a ' ' and non-keywords use a ' ' Your Solution: Have attributes that apply to variables use no ' ' and all other attributes use a ' '. You've changed the cutoff from "keywords" to "whether or not they apply to variables". How does this solve the original problem (stated above)? void foo() pure safe const; // OR public pure final safe foo(); How is this more consistent? This doesn't solve the problem is just shuffles around the cases when we use ' ' and when we don't. Note: not to mention that it still looks horrible to use ' '. There's no reason the language needs to require a ' ' on a keyword. The only reason is to make things consistent but if you're not making things more consistent, as shown above.On Tuesday, 27 January 2015 at 17:18:11 UTC, Nick Treleaven wrote:Yes, because it affects the class's functions, not its variable members.On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote:I think you may have missed the point. I believe what Jonathan is saying is that if you turn abstract into abstract then you have to consider how to solve the "abstract class" issue. Do you change it to: abstract class ?abstract also applies to classes, as does final.Yes, but they actually only affect the *functions* belonging to the class, not the variables. A class is not a variable.Same thing with final. Since the same keywords are used in a lot of different contexts, if you change how it is used in one context then it's going to be inconsistent with how it's used in the other contexts (like with a function or a class). Then if you want consistency (which is the point of why we are discussing this change in the first place) you have to change every context it is used in. If you follow through with your proposal, you'll end up putting a ' ' character before almost every keyword in the languageIn that case I don't think you've really grokked my proposal. It only requires 5 changes to attributes for consistency (and that's counting pure and nothrow).
Jan 27 2015
On Tuesday, 27 January 2015 at 18:21:37 UTC, Nick Treleaven wrote:Probably unimportant, but no, abstract and final apply to classes, not to members. tl;dr what's problem with applying attributes to classes? Classes can have various attributes, abstract and final are just among them. I would recommend this formatting: --- abstract final notypeinfo class ... ---I think you may have missed the point. I believe what Jonathan is saying is that if you turn abstract into abstract then you have to consider how to solve the "abstract class" issue. Do you change it to: abstract class ?Yes, because it affects the class's functions, not its variable members.
Jan 28 2015
On 2015-01-27 17:49, Jonathan M Davis via Digitalmars-d wrote:IMHO, if we have to search for a way to make them consistent, then there's no point. We're just going to end up with making things more consistent in one way and less in another without necessarily making it any easier for anyone to keep track of, so we'd just be shuffling things around. I think that there needs to be a clear and solid benefit to changing which attributes have and which don't, or we shouldn't mess with them.We could change all attributes to be compiler recognized UDA's, which would require prefixing them with . All current attributes would be removed. This is of course a major breaking change and will not happen. Since they would be UDA's it would be possible to disambiguate with other UDA's with the same name in another module. -- /Jacob Carlborg
Jan 27 2015
Jonathan M Davis via Digitalmars-d pÃÅ¡e v Út 27. 01. 2015 v 08:49 -0800:On Tuesday, January 27, 2015 11:47:04 Nick Treleaven via Digitalmars-d wrote:Exactly I do not think we can (want to) be 100% consistent . Even If I really like to see every attribute to be with or without (because consistency). I do not think it will be perfect. For eg. one of things I rewrite some of my code from PHP consist with following steps: 1.) remove $ 2.) replace :: and -> for . 3.) some minor changes (sometimes nothing) So I would prefer if private, public, protected, final, static stay without , but D specific things like pure,immutable,nothrow,nogc,safe,trust,disable,deprecated... would go with if I speak about immutable(const) I only mean function attribut not storage. And It would be perfect if all theese must be on the right side: // OK public final void someFunc() immutable safe nogc nothrow { } // OK public final immutable(int) someFunc() immutable safe nogc nothrow { return 5 } // Deprecated public final immutable int someFunc() immutable safe nogc nothrow { return 5 } // Error or Deprecated public final immutable int someFunc() safe nogc nothrow { return 5 }On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote:abstract also applies to classes, as does final. Also, if we end up adding any new attributes later, they're bound to have on them to avoid requiring a keyword (which is why we have on some of them in the first place), and if the new attribute applies to variables or types as well, then the division that you're suggesting falls apart. IMHO, if we have to search for a way to make them consistent, then there's no point. We're just going to end up with making things more consistent in one way and less in another without necessarily making it any easier for anyone to keep track of, so we'd just be shuffling things around. I think that there needs to be a clear and solid benefit to changing which attributes have and which don't, or we shouldn't mess with them.You're right. I forgot about those two. But it's still the case that the number of function attributes that don't have on them is_far_ greater than the number of those that do.But I explained that most function attributes don't only apply to functions but to variables as well: public, protected, package, private, static, const, immutable, inout, and deprecated So it can be consistent that the above don't use . These only affect functions, not variables, so should be attributes IMO: final, override, abstract These affect both: return, ref So if we want some kind of consistency, we can achieve it by adding for final, override, abstract, and removing it for 'return'.
Jan 27 2015
On Tuesday, 27 January 2015 at 21:15:16 UTC, Daniel Kozak wrote:Jonathan M Davis via Digitalmars-d pÃÅ¡e v Út 27. 01. 2015 v 08:49 -0800:Good idea. The only think I would change is when an attribute appears on the right side, why not omit the ' ' symbol :) Other then that I like the consistency of putting the attributes in the same place. But even if you kept the ' ' symbol I would still prefer your proposal over what we have now. It's more consistent and no longer looks weird. When someone new comes along it makes sense and doesn't look like a hack.On Tuesday, January 27, 2015 11:47:04 Nick Treleaven via Digitalmars-d wrote:Exactly I do not think we can (want to) be 100% consistent . Even If I really like to see every attribute to be with or without (because consistency). I do not think it will be perfect. For eg. one of things I Even rewrite some of my code from PHP consist with following steps: 1.) remove $ 2.) replace :: and -> for . 3.) some minor changes (sometimes nothing) So I would prefer if private, public, protected, final, static stay without , but D specific things like pure,immutable,nothrow,nogc,safe,trust,disable,deprecated... would go with if I speak about immutable(const) I only mean function attribut not storage. And It would be perfect if all theese must be on the right side: // OK public final void someFunc() immutable safe nogc nothrow { } // OK public final immutable(int) someFunc() immutable safe nogc nothrow { return 5 } // Deprecated public final immutable int someFunc() immutable safe nogc nothrow { return 5 } // Error or Deprecated public final immutable int someFunc() safe nogc nothrow { return 5 }On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote:abstract also applies to classes, as does final. Also, if we end up adding any new attributes later, they're bound to have on them to avoid requiring a keyword (which is why we have on some of them in the first place), and if the new attribute applies to variables or types as well, then the division that you're suggesting falls apart. IMHO, if we have to search for a way to make them consistent, then there's no point. We're just going to end up with making things more consistent in one way and less in another without necessarily making it any easier for anyone to keep track of, so we'd just be shuffling things around. I think that there needs to be a clear and solid benefit to changing which attributes have and which don't, or we shouldn't mess with them.You're right. I forgot about those two. But it's still the case that the number of function attributes that don't have on them is_far_ greater than the number of those that do.But I explained that most function attributes don't only apply to functions but to variables as well: public, protected, package, private, static, const, immutable, inout, and deprecated So it can be consistent that the above don't use . These only affect functions, not variables, so should be attributes IMO: final, override, abstract These affect both: return, ref So if we want some kind of consistency, we can achieve it by adding for final, override, abstract, and removing it for 'return'.
Jan 27 2015
On 26/01/2015 11:39, Jonathan M Davis via Digitalmars-d wrote:the increased visual noise definitely is not.Being able to ignore things starting with is useful when reading function signatures: property const(T) pure nothrow foo(Arg arg, T bar) const ... So can actually be signal rather than noise.
Jan 26 2015
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote:Personally, I'd much prefer that we not make this change. It's just shuffling things around in an attempt to make them more consistent while actually making them _less_ consistent. - Jonathan M DavisI don't think this problem is solvable without "dfix". Here are the factors I would consider: 1. ` ` is ugly. Therefore it would be great to make `safe`, `trusted`, `system`, and `nogc` full-fledged keywords, to spare future readers of code all those ` `s. So long as it's definitely a permanent feature of the language, it should look as good as possible. (`property` too, if we're sure it's not leaving). ` ` is then left exclusively for UDAs, an improvement, IMO. 2. Consistency of attribute usage is important. All built-in attributes should be markable in the same way, either with, or without an ` ` sign. 3. Singularity of usage also matters. There should only be one way to mark a given attribute, either with or without ` `. 4. Old code matters. Existing code puts points 2 and 3 into conflict. Now it goes without saying that changing old code is a nuisance. But it's important to point out that not all code changes are the same. In the interest of furthering this discussion, here is a list of the types of breaking changes, in my order of least to most desirable: B1. Silent breaking changes. Same code now does different things. Rightly regarded as the worst kind. You don't even know what hit you. B2. Completely pointless changes. For the record, I'm against changes which literally have no benefit. Most changes which get seriously discussed, however, involve difficult tradeoffs, for which the assumed benefit must outweigh the perceived loss, plus the "switching costs". The point of this list is to emphasize that not all switching costs are the same, and that they depend greatly on the *individual* change. B3. Breaking changes which require significant redesign of code. Sociomantic faces this issue with their move to D2. B4. Changes which can easily be fixed, with the right know-how. Great error messages, referring the user to the documentation of these changes and how to fix them, is essential. B5. The kind that a tool such as 'dfix', can automate. For example, let's say dfix is included with the compiler package. Now you get an error, saying: "Error: ` nogc` is no longer accepted, but can be automatically replaced with `nogc`. Run dfix on this file? (y/n)"... or whatever is deemed the secure approach to this feature. B6. Changes which catch existing bugs, with no false positives. Obviously wins. The changes suggested in this thread are of kind 5.5. But more people would have to get behind the whole 'dfix' approach for it to work. "Most D code is yet to be written. #PleaseBreakOurCode." +1
Jan 26 2015
On Monday, 26 January 2015 at 19:02:27 UTC, Zach the Mystic wrote:The changes suggested in this thread are of kind 5.5.s/5.5/B5
Jan 26 2015
"5. The kind that a tool such as 'dfix', can automate. For example, let's say dfix is included with the compiler package. Now you get an error, saying: "Error: ` nogc` is no longer accepted, but can be automatically replaced with `nogc`. Run dfix on this file? (y/n)"... or whatever is deemed the secure approach to this feature. " Sorry for the tangent (I have no view on the major topic), +1 for including a link to dfix within the compiler. Repetitive things ought to be automated and made easy and how many times does one end up fixing up old code ?
Jan 26 2015
On 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:Personally, I'd much prefer that we not make this change.It's good to have this discussion. Previously, it's all been advocacy and "break my code" by forcing a change from pure => pure. Just a few days ago on slashdot, an anonymous D user wrote: "A horrible mix of keywords and annotation syntax for function/method attributes ('const', 'pure', and 'nothrow' are all keywords, but ' property', and ' nogc' are annotations)" for why he won't use D anymore. Frankly, I think that is a great bikeshedding non-issue that distracts us from what is important. I hope that by doing this PR, we can actually decide that it isn't worth it, i.e. I'd be happy to get consensus and revert it.
Jan 26 2015
On Mon, Jan 26, 2015 at 11:50:19AM -0800, Walter Bright via Digitalmars-d wrote:On 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:While I generally agree with the sentiment that this great debate over syntax is distracting from more important issues, one particularly attractive point about forcing on annotations is that const (as a type qualified) and const (as a function annotation) become syntactically distinct: const int myFunc() const {} vs. the current confusing syntax: const int myFunc() const {} Does this alone make it worth it? I'm skeptical. But I thought it should be pointed out regardless. T -- If it tastes good, it's probably bad for you.Personally, I'd much prefer that we not make this change.It's good to have this discussion. Previously, it's all been advocacy and "break my code" by forcing a change from pure => pure. Just a few days ago on slashdot, an anonymous D user wrote: "A horrible mix of keywords and annotation syntax for function/method attributes ('const', 'pure', and 'nothrow' are all keywords, but ' property', and ' nogc' are annotations)" for why he won't use D anymore. Frankly, I think that is a great bikeshedding non-issue that distracts us from what is important. I hope that by doing this PR, we can actually decide that it isn't worth it, i.e. I'd be happy to get consensus and revert it.
Jan 26 2015
On Monday, 26 January 2015 at 19:59:58 UTC, H. S. Teoh wrote:On Mon, Jan 26, 2015 at 11:50:19AM -0800, Walter Bright via Digitalmars-d wrote:I wouldn't count `const` among functions annotations. It applies to `this`, not to the function.On 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:While I generally agree with the sentiment that this great debate over syntax is distracting from more important issues, one particularly attractive point about forcing on annotations is that const (as a type qualified) and const (as a function annotation) become syntactically distinct: const int myFunc() const {} vs. the current confusing syntax: const int myFunc() const {} Does this alone make it worth it? I'm skeptical. But I thought it should be pointed out regardless.Personally, I'd much prefer that we not make this change.It's good to have this discussion. Previously, it's all been advocacy and "break my code" by forcing a change from pure => pure. Just a few days ago on slashdot, an anonymous D user wrote: "A horrible mix of keywords and annotation syntax for function/method attributes ('const', 'pure', and 'nothrow' are all keywords, but ' property', and ' nogc' are annotations)" for why he won't use D anymore. Frankly, I think that is a great bikeshedding non-issue that distracts us from what is important. I hope that by doing this PR, we can actually decide that it isn't worth it, i.e. I'd be happy to get consensus and revert it.
Jan 28 2015
It was sad that calls for more breakage were mostly ignored. But there is one thing now that is even worse - referring to #pleasebreakmycode as an excuse to introduce random changes based on random reddit comment - and completely dismissing everything that was said on topic initially. Resulting in exactly the opposite action that was asked to. Please, revert this PR asap. After that it can possibly be introduced after meeting necessary prerequisites: 1) explanation of problem it fixes 2) design rationale for new model 3) evaluation of ROI 4) tools for simple migration - either as part of dfix or compiler This is absolutely mandatory list for any change of language fundamentals to be considered legitimate.
Jan 26 2015
On 1/26/2015 12:26 PM, Dicebot wrote:It was sad that calls for more breakage were mostly ignored. But there is one thing now that is even worse - referring to #pleasebreakmycode as an excuse to introduce random changes based on random reddit comment - and completely dismissing everything that was said on topic initially. Resulting in exactly the opposite action that was asked to.I can't find Don's original post on the topic.
Jan 26 2015
On Monday, 26 January 2015 at 20:56:36 UTC, Walter Bright wrote:On 1/26/2015 12:26 PM, Dicebot wrote:Donno If you are referring to this [1], but at least it's about this pull... --- Paolo [1] http://forum.dlang.org/thread/bug-13388-3 https.issues.dlang.org%2F?page=3#post-mailman.312.1409643575.5783.digitalmars-d-bugs:40puremagic.comIt was sad that calls for more breakage were mostly ignored. But there is one thing now that is even worse - referring to #pleasebreakmycode as an excuse to introduce random changes based on random reddit comment - and completely dismissing everything that was said on topic initially. Resulting in exactly the opposite action that was asked to.I can't find Don's original post on the topic.
Jan 26 2015
On 1/26/2015 1:07 PM, Paolo Invernizzi wrote:On Monday, 26 January 2015 at 20:56:36 UTC, Walter Bright wrote:Yup, that's it. Your search-foo is better than mine! A more direct link: https://issues.dlang.org/show_bug.cgi?id=13388#c27On 1/26/2015 12:26 PM, Dicebot wrote:Donno If you are referring to this [1], but at least it's about this pull... [1] http://forum.dlang.org/thread/bug-13388-3 https.issues.dlang.org%2F?page=3#post-mailman.312.1409643575.5783.digitalmars-d-bugs:40puremagic.comIt was sad that calls for more breakage were mostly ignored. But there is one thing now that is even worse - referring to #pleasebreakmycode as an excuse to introduce random changes based on random reddit comment - and completely dismissing everything that was said on topic initially. Resulting in exactly the opposite action that was asked to.I can't find Don's original post on the topic.
Jan 26 2015
On Monday, 26 January 2015 at 21:17:50 UTC, Walter Bright wrote:I was referring to earlier posts (as old as Don's dconf 2013 talk ;)) However my complaint is not about the change itself (though I personally disagree with Don reasoning in that issue, it is a delicate matter) but about the fact that it is again done as a casual PR and our breaking change culture does not seem to change : it is still all or nothing approach. No automatic migration tools, no easily found rationale / explanation, no posts in D.announce - just an ordinary commit. No wonder any of more notable change is considered that scary.Donno If you are referring to this [1], but at least it's about this pull... [1] http://forum.dlang.org/thread/bug-13388-3 https.issues.dlang.org%2F?page=3#post-mailman.312.1409643575.5783.digitalmars-d-bugs:40puremagic.comYup, that's it. Your search-foo is better than mine! A more direct link: https://issues.dlang.org/show_bug.cgi?id=13388#c27
Jan 26 2015
On 1/26/2015 1:29 PM, Dicebot wrote:However my complaint is not about the change itself (though I personally disagree with Don reasoning in that issue, it is a delicate matter) but about the fact that it is again done as a casual PR and our breaking change culture does not seem to change : it is still all or nothing approach. No automatic migration tools, no easily found rationale / explanation, no posts in D.announce - just an ordinary commit. No wonder any of more notable change is considered that scary.What I wanted by doing this is to produce some sort of consensus. The topic has already been discussed to death.
Jan 26 2015
On 2015-01-26 23:04, Walter Bright wrote:What I wanted by doing this is to produce some sort of consensus. The topic has already been discussed to death.You have complained that one of your old D1 projects didn't compile with the latest D2 compiler. How would you expect that to still compile when making changes like this and without those things Dicebot mentioned. -- /Jacob Carlborg
Jan 27 2015
On 1/27/2015 2:14 AM, Jacob Carlborg wrote:You have complained that one of your old D1 projects didn't compile with the latest D2 compiler. How would you expect that to still compile when making changes like this and without those things Dicebot mentioned.This change didn't break a single line in the libraries or the test suite.
Jan 27 2015
On Tuesday, 27 January 2015 at 10:50:53 UTC, Walter Bright wrote:This change didn't break a single line in the libraries or the test suite.Yes, but it didn't also fix anything, only introduced more ways to do the same thing - without any plans for some consistent model. It is simply moving things around for the sake of marking some bugzilla report as closed - there is no consistent rationale for applying to attributes available. Just the fact that change can't possibly break anything doesn't mean it is can't have negative value. It _may_ have some well-though rationale behind I am failing to spot but that is not presented to users in any way.
Jan 28 2015
Dicebot:Yes, but it didn't also fix anything, only introduced more ways to do the same thing - without any plans for some consistent model.One of the rules of the Python Zen: There should be one-- and preferably only one --obvious way to do it. The word "obvious" is important, because usually there are multiple ways to do something, but only one of them should be obvious in Python :-) Bye, bearophile
Jan 28 2015
On Wednesday, 28 January 2015 at 13:14:16 UTC, bearophile wrote:Dicebot:I am aware of Python Zen and generally it is not applicable to D. Multiple ways of doing the same thing can be justified both for backwards compatibility and pragmatical reason. But in this case I see no improvement that could justify it. I'd welcome the change to attribute syntax but only one that actually fixes the problems and not just rearranges things.Yes, but it didn't also fix anything, only introduced more ways to do the same thing - without any plans for some consistent model.One of the rules of the Python Zen: There should be one-- and preferably only one --obvious way to do it. The word "obvious" is important, because usually there are multiple ways to do something, but only one of them should be obvious in Python :-)
Jan 28 2015
On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote:But in this case I see no improvement that could justify it.Fixes problems people have with inconsistent attribute syntax, see discussion at https://issues.dlang.org/show_bug.cgi?id=13388
Jan 28 2015
On Wednesday, 28 January 2015 at 14:30:47 UTC, Kagamin wrote:On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote:Yes, but as it has been already mentioned in this thread new system is as much inconsistent - it simply has moved 3 of attributes from one "camp" to another. If idea was to separate attributes that affect mangling/type then we still have protection attributes. And with no plans to deprecate old syntax even more inconsistency had been introduced. Same goes for possible introduction of new attributes - if syntax for those and UDA is identical, it can break code same as introducing new keywords. I don't see any _vision_ behind the change, just moving bits around. It is not well-thought.But in this case I see no improvement that could justify it.Fixes problems people have with inconsistent attribute syntax, see discussion at https://issues.dlang.org/show_bug.cgi?id=13388
Jan 28 2015
On Wednesday, January 28, 2015 14:41:08 Dicebot via Digitalmars-d wrote:On Wednesday, 28 January 2015 at 14:30:47 UTC, Kagamin wrote:Exactly. It's not like this is simply a discussion of whether a change which makes the language more consistent is worth the breaking changes that it causes. Rather, The change doesn't actually fix anything. It just moves stuff around. If more things were moved around, then maybe they'd become more consistent and would actually help the situation, but that's not what's happened. A few were attributes moved from one camp to the other with no real plan, and because it took attributes from the smaller camp and put them in the larger one, it's actually decreasing consistency and making the situation worse rather than improving it. If we're going to shuffle attributes around, we need to do it in a way that actually follows a plan and makes the language more consistent. That's not what's happening here. We either need to come up with a complete plan for shuffling attributes around in a way that will actually make them fully consistent, or we need to revert these changes and stick with the status quo. Anything else just shuffles things around without fixing the problem, and it increases confusion in the process. And honestly, after several discussions on this in the past, I don't think that it's actually possible to make the attributes fully consistent. They're always going to be inconsistent in one way or another, even if it's simply because they don't match what anyone coming from other languages expects (e.g. on a whole bunch of keywords like private or final that other languages don't put on and which none of the current D literature or code out there puts on). I think that this is a case of folks trying to shuffle things around to fix something that just can't be fixed. At best, it'll just end up being ugly in a different way. - Jonathan M DavisOn Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote:Yes, but as it has been already mentioned in this thread new system is as much inconsistent - it simply has moved 3 of attributes from one "camp" to another. If idea was to separate attributes that affect mangling/type then we still have protection attributes. And with no plans to deprecate old syntax even more inconsistency had been introduced. Same goes for possible introduction of new attributes - if syntax for those and UDA is identical, it can break code same as introducing new keywords. I don't see any _vision_ behind the change, just moving bits around. It is not well-thought.But in this case I see no improvement that could justify it.Fixes problems people have with inconsistent attribute syntax, see discussion at https://issues.dlang.org/show_bug.cgi?id=13388
Jan 28 2015
On Wednesday, 28 January 2015 at 15:11:35 UTC, Jonathan M Davis wrote:consistent. They're always going to be inconsistent in one way or another, even if it's simply because they don't match what anyone coming from other languages expectsThe logical conclusion from that statement would be that D semantics are fundamentally broken...
Jan 28 2015
On Wednesday, January 28, 2015 15:16:50 via Digitalmars-d wrote:On Wednesday, 28 January 2015 at 15:11:35 UTC, Jonathan M Davis wrote:Not really. For instance, we could make the attributes "completely consistent" by adding to all of them - pure, public, const, etc. But that would cause inconsistencies with other languages that have many of the same attributes, and it would likely cause far more complaining than the current situation has. We could also remove from all of the attributes, and then that would be "completely consistent," because then only UDAs will have on them. But the next time that we need to add a new attribute (which will hopefully be rare, but it happens sometimes - e.g. with nogc recently), then we'd have to add a new keyword to avoid making things inconsistent, which would likely break existing code. So, more likely, we'd just tack onto it (which can still break code, but only UDA-specific code, so the breakage would be far more minimal), and we'd be right back where we are now. And any situation where some of the attributes have on them and some don't will almost certainly result in arguments about whether the rationale makes sense and whether one or more of the attributes really belongs in the camp that it's in, so how consistent it is would depend on the eye of the beholder. I don't see any of that as being something fundamentally broken with the semantics of D. It's just life with designing a programming language - especially one which isn't 100% set in stone. There are _always_ inconsistencies and annoying points in the language. And much of the time, those inconsistencies and annoying points are forced by other aspects of the language that actually make things nice and clean. There are always tradeoffs, and often, there is no clear, right answer to how it should be. And I think that this is one of those cases. - Jonathan M Davisconsistent. They're always going to be inconsistent in one way or another, even if it's simply because they don't match what anyone coming from other languages expectsThe logical conclusion from that statement would be that D semantics are fundamentally broken...
Jan 28 2015
On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis wrote:On Wednesday, January 28, 2015 15:16:50 via Digitalmars-d wrote:Actually we could support removing the ' ' symbol from all attributes without making them keywords :) It would be quite simple to do (probably a day of work in DMD, in parser.c and a couple other places that use the code tree). At least for the attributes on the right side of the function signature. For the attributes on the left-hand side, it may make the syntax ambiguous...not sure. The idea is we allow non-keyword identifiers to be used as function attributes (on the right hand side).On Wednesday, 28 January 2015 at 15:11:35 UTC, Jonathan M Davis wrote:Not really. For instance, we could make the attributes "completely consistent" by adding to all of them - pure, public, const, etc. But that would cause inconsistencies with other languages that have many of the same attributes, and it would likely cause far more complaining than the current situation has. We could also remove from all of the attributes, and then that would be "completely consistent," because then only UDAs will have on them. But the next time that we need to add a new attribute (which will hopefully be rare, but it happens sometimes - e.g. with nogc recently), then we'd have to add a new keyword to avoid making things inconsistent, which would likely break existing code. So, more likely, we'd just tack onto it (which can still break code, but only UDA-specific code, so the breakage would be far more minimal), and we'd be right back where we are now.consistent. They're always going to be inconsistent in one way or another, even if it's simply because they don't match what anyone coming from other languages expectsThe logical conclusion from that statement would be that D semantics are fundamentally broken...
Jan 28 2015
On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis wrote:inconsistencies and annoying points in the language. And much of the time, those inconsistencies and annoying points are forced by other aspects of the language that actually make things nice and clean. There are always tradeoffs, and often, there is no clear, right answer to how it should be.I think I misinterpreted what you meant to say, but if the semantics are good and sound then you should be able to device a consistent syntax for the language that is in line with current terminology in comp sci (even if that means pointing to Wikipedia for a definition of the term). That would of course mean a lot of changes to D terminology: "const" => "readonly" "enum" => "const" "range"=>"iterator" "pure"=>"no global effect" "ubyte" => "byte" "lazy" => "by name" etc...
Jan 28 2015
On Wednesday, January 28, 2015 16:10:28 via Digitalmars-d wrote:On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis wrote:I don't see what any of that has to do with which attributes have on them or not. The problem is that any situation where some of the attributes have and some don't is going to cause some confusion, whereas putting on all of them would create inconsistencies with the expectations of folks coming from other languages and make porting code to D more annoying, and putting on none of them means that we're consistent but would mean that every time that we had to introduce a new built-in attribute (which we don't want to do much more of, but it still happens occasionally), we would either break existing code (because it would mean introducing a new keyword), or we'd have to put on it (making things inconsistent again, but only risking breaking UDA code, which is less prevalent). If we could start from scratch and guarantee that no new attributes would ever be introduced, then we could just put on none of them and thus be fully consistent. But we can't start from scratch, and we can't guarantee that there will be no new attributes. And even then, instead of getting complaints about being inconsistent with , then we'd get even more complaints about the number of keywords that we have. There is no way to win here. No matter what we do, there will be screaming from someone. And whether the language would be objectively improved would be debatable. There may be set of changes that would ultimately be better enough that they'd be worth making - where the pros are generally considered to outweigh the cons - but we'll be stuck with the cons regardless, and I seriously question that any change to attribute names is enough of an improvement to merit the code breakage that it would cause, even if it were objectively better. - Jonathan M Davisinconsistencies and annoying points in the language. And much of the time, those inconsistencies and annoying points are forced by other aspects of the language that actually make things nice and clean. There are always tradeoffs, and often, there is no clear, right answer to how it should be.I think I misinterpreted what you meant to say, but if the semantics are good and sound then you should be able to device a consistent syntax for the language that is in line with current terminology in comp sci (even if that means pointing to Wikipedia for a definition of the term). That would of course mean a lot of changes to D terminology: "const" => "readonly" "enum" => "const" "range"=>"iterator" "pure"=>"no global effect" "ubyte" => "byte" "lazy" => "by name" etc...
Jan 28 2015
On Wednesday, 28 January 2015 at 16:39:51 UTC, Jonathan M Davis wrote:I don't see what any of that has to do with which attributes have on them or not.As I said, I misinterpreted what you wrote. You came through as being overly defensive when it comes to accepting a syntax with bad usability. It does affect both usability and marketing what the syntax looks like and whether the terminology is consistent with definitions. It sends signals about the design and the implementation that will be picked up by people who evaluate the language. For instance, the syntax of Cray's Chapel sends strong signals of the designers know what they are doing, so I am more inclined to give it a spin...If we could start from scratch and guarantee that no new attributes would ever be introduced, then we could just put on none of them and thus be fully consistent. But we can't start from scratch, and we can't guarantee that there will be no new attributes.Of course you can, but you need to get the semantics right first.There may be set of changes that would ultimately be better enough that they'd be worth making - where the pros are generally considered to outweigh the cons - but we'll be stuck with the cons regardless, and I seriously question that any change to attribute names is enough of an improvement to merit the code breakage that it would cause, even if it were objectively better.That's one viewpoint. An alternative viewpoint is that when/if D has reached a stable state, then it is a relatively small task for someone (1-2 people) to fork the language, design a new grammar and implement a parser for it that maps to the compiler internals. It is not a big project to write a new parser if the rest is stable. Syntactical code breakage is not a real problem, since: 1. the D corpus is small 2. transpilers can do source-to-source compilation 3. a compiler can include multiple parsers for the same language semantics Except... string mixins.
Jan 28 2015
If we could start from scratch and guarantee that no new attributes would ever be introduced, then we could just put on none of them and thus be fully consistent. But we can't start from scratch, and we can't guarantee that there will be no new attributes. And even then, instead of getting complaints about being inconsistent with , then we'd get even more complaints about the number of keywords that we have. There is no way to win here. No matter what we do, there will be screaming from someone. And whether the language would be objectively improved would be debatable.I have proposed a way that I think is a win win. Add support for non-keyword function attributes on the right hand side of a function signature. This will not break any code since it does not require removing support for using ' ' for function attributes. Then later we can deprecate support for the ' ' character if we feel like it's worth breaking code. void foo() safe; // now valid, and safe is not a keyword safe void foo(); // still not valid, might make the grammar // ambiguous, if it does not then it could // be supported later void foo() safe; // Still ok (can be deprecated) It's simple to remember that if you put the function attribute on the right hand side then no ' ' is required. Plus, this will encourage developers to put their attributes on the right hand side in the future so they can remove the ' ' character. PLUS, this would be very simple to implement!There may be set of changes that would ultimately be better enough that they'd be worth making - where the pros are generally considered to outweigh the cons - but we'll be stuck with the cons regardless, and I seriously question that any change to attribute names is enough of an improvement to merit the code breakage that it would cause, even if it were objectively better.My proposal will not break any code.
Jan 28 2015
On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:I have proposed a way that I think is a win win. Add support for non-keyword function attributes on the right hand side of a function signature. This will not break any code since it does not require removing support for using ' ' for function attributes. Then later we can deprecate support for the ' ' character if we feel like it's worth breaking code.I agree. This would also be a nice way to introduce dfix. And while we're at it, we can also move `const` etc. applying to the implicit `this` to the right side, too, so that this falltrap goes away, too.
Jan 28 2015
On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:PLUS, this would be very simple to implement!Then I recommend you submit a pull request. Mike
Jan 28 2015
On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:I would but Walter said no. I'm certain he misunderstood my proposal and I tried to explain it to him but I couldn't get him to address it. I'm not sure what to do here. If I get the go ahead from Walter or anyone who would be able to merge the PR then I would happily do the work :) For some reason no one with power is addressing my proposal. Andrei? Jonathan? Dicebot? Walter? Walter I know you've been responding to most of my posts, but again, I think you are misinterpreting my proposal. For some reason it seems like you think I'm trying to make the lexer be context-sensitive. My proposal would not touch the lexer.PLUS, this would be very simple to implement!Then I recommend you submit a pull request. Mike
Jan 28 2015
On 1/28/15 10:19 AM, Jonathan Marler wrote:On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:Was that the proposal leading to this state of affairs (quoting from your post on 2015/01/26 16:05 PST?On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:I would but Walter said no. I'm certain he misunderstood my proposal and I tried to explain it to him but I couldn't get him to address it.PLUS, this would be very simple to implement!Then I recommend you submit a pull request. MikeHere's what would change ----------------------------------------------------------------- void myfunc() nogc; // VALID (Only if this proposal is accepted) void myfunc() safe; // VALID (Only if this proposal is accepted) Here's what WOULD NOT change ----------------------------------------------------------------- nogc myfunc(); // STILL INVALID: invalid unless it can be verified // that this wouldn't result in ambiguity // in the grammar void myfunc() nogc; // STILL VALID (no change) nogc myfunc(); // STILL VALID (no change)Andrei
Jan 28 2015
On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei Alexandrescu wrote:On 1/28/15 10:19 AM, Jonathan Marler wrote:You can follow this thread: http://forum.dlang.org/post/fxbqqecgqdhrepxsjnep forum.dlang.org I explained my proposal 3 or 4 times but each time Walter seemed to be misunderstanding my proposal saying it was going to create "context-sensitive" tokens and so he would immediately dismiss it. I tried to understand what he meant by "context-sensitive" tokens because my proposal didn't have anything to do with them (at least my definition of them), but even after he defined them my proposal clearly does not create them. Walter "[A context-sensitive token is] A keyword in one context and an identifier in another" Anyway, I'll restate my proposal again: 1. Modify the SYNTAX of function to allow it to be decorated with IDENTIFIER tokens on the right hand side void foo() x; // valid SYNTAX (note: has not semantic meaning) void foo() safe; // valid SYNTAX and valid SEMANTICS 2. Modify the code that interprets the syntax tree to recognize these identifiers as function attributes. A simple solution that would allow us to standardize where we put the function attributes and allow us to remove the ' ' character from all non-keyword function attributes. Seems like a no-brainer to me.On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:Was that the proposal leading to this state of affairs (quoting from your post on 2015/01/26 16:05 PST?On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:I would but Walter said no. I'm certain he misunderstood my proposal and I tried to explain it to him but I couldn't get him to address it.PLUS, this would be very simple to implement!Then I recommend you submit a pull request. MikeHere's what would change ----------------------------------------------------------------- void myfunc() nogc; // VALID (Only if this proposal is accepted) void myfunc() safe; // VALID (Only if this proposal is accepted) Here's what WOULD NOT change ----------------------------------------------------------------- nogc myfunc(); // STILL INVALID: invalid unless it can be verified // that this wouldn't result in ambiguity // in the grammar void myfunc() nogc; // STILL VALID (no change) nogc myfunc(); // STILL VALID (no change)Andrei
Jan 28 2015
On 1/28/15 10:37 AM, Jonathan Marler wrote:On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei Alexandrescu wrote:That's not a misunderstanding. Your proposal has been understood. It can be made to work. That doesn't necessarily make it desirable. I don't think it's particularly helpful and Walter is against it, so simply put it won't happen. Let it go. Thanks for it and keep the good ideas coming. -- AndreiOn 1/28/15 10:19 AM, Jonathan Marler wrote:You can follow this thread: http://forum.dlang.org/post/fxbqqecgqdhrepxsjnep forum.dlang.org I explained my proposal 3 or 4 times but each time Walter seemed to be misunderstanding my proposal saying it was going to create "context-sensitive" tokens and so he would immediately dismiss it. I tried to understand what he meant by "context-sensitive" tokens because my proposal didn't have anything to do with them (at least my definition of them), but even after he defined them my proposal clearly does not create them. Walter "[A context-sensitive token is] A keyword in one context and an identifier in another" Anyway, I'll restate my proposal again: 1. Modify the SYNTAX of function to allow it to be decorated with IDENTIFIER tokens on the right hand side void foo() x; // valid SYNTAX (note: has not semantic meaning) void foo() safe; // valid SYNTAX and valid SEMANTICS 2. Modify the code that interprets the syntax tree to recognize these identifiers as function attributes. A simple solution that would allow us to standardize where we put the function attributes and allow us to remove the ' ' character from all non-keyword function attributes. Seems like a no-brainer to me.On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:Was that the proposal leading to this state of affairs (quoting from your post on 2015/01/26 16:05 PST?On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:I would but Walter said no. I'm certain he misunderstood my proposal and I tried to explain it to him but I couldn't get him to address it.PLUS, this would be very simple to implement!Then I recommend you submit a pull request. MikeHere's what would change ----------------------------------------------------------------- void myfunc() nogc; // VALID (Only if this proposal is accepted) void myfunc() safe; // VALID (Only if this proposal is accepted) Here's what WOULD NOT change ----------------------------------------------------------------- nogc myfunc(); // STILL INVALID: invalid unless it can be verified // that this wouldn't result in ambiguity // in the grammar void myfunc() nogc; // STILL VALID (no change) nogc myfunc(); // STILL VALID (no change)Andrei
Jan 28 2015
I don't have a problem with letting things go. What I have a problem with is poor communication. Walter never gave me a "valid" reason for why he didn't like the proposal. I'm totally ok if it gets rejected, but I have no idea why it was rejected. If anything, I just want to understand so that I make better decisions in the future. When I say he misunderstood I say that because the reason he gave for disliking the proposal doesn't make sense. He's using the "Straw Man" logical fallacy. He's attacking my proposal by assuming it's something that it isn't. He keeps mentioning keywords and "context-sensitive" tokens but my proposal has nothing to do with those things (even by his own definition of them). Quite frustrating. I hope you see that I'm just trying to understand. I don't care if I'm wrong, I just want someone to tell my why I'm wrong. And when someone asks me why we weren't able to make function attributes that weren't keywords, I can give them an answer.On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei Alexandrescu wrote:That's not a misunderstanding. Your proposal has been understood. It can be made to work. That doesn't necessarily make it desirable. I don't think it's particularly helpful and Walter is against it, so simply put it won't happen. Let it go. Thanks for it and keep the good ideas coming. -- Andrei
Jan 28 2015
On 1/28/15 10:59 AM, Jonathan Marler wrote:It may be the case you're using different definitions of the term "contextual keyword". Far as I can tell you want the identifier "nogc" be recognized in certain places by the compiler as special, and otherwise just not be special at all. That's a contextual keyword. If that's the case you were well understood by both Walter and myself. I happen to recognize the merit of contextual keyword in general, but Walter has a stronger opposition to it. It doesn't seem to me this particular application is compelling enough to warrant the precedent. -- AndreiI don't have a problem with letting things go. What I have a problem with is poor communication. Walter never gave me a "valid" reason for why he didn't like the proposal. I'm totally ok if it gets rejected, but I have no idea why it was rejected. If anything, I just want to understand so that I make better decisions in the future. When I say he misunderstood I say that because the reason he gave for disliking the proposal doesn't make sense. He's using the "Straw Man" logical fallacy. He's attacking my proposal by assuming it's something that it isn't. He keeps mentioning keywords and "context-sensitive" tokens but my proposal has nothing to do with those things (even by his own definition of them). Quite frustrating. I hope you see that I'm just trying to understand. I don't care if I'm wrong, I just want someone to tell my why I'm wrong. And when someone asks me why we weren't able to make function attributes that weren't keywords, I can give them an answer.On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei Alexandrescu wrote:That's not a misunderstanding. Your proposal has been understood. It can be made to work. That doesn't necessarily make it desirable. I don't think it's particularly helpful and Walter is against it, so simply put it won't happen. Let it go. Thanks for it and keep the good ideas coming. -- Andrei
Jan 28 2015
On Wednesday, 28 January 2015 at 19:04:50 UTC, Andrei Alexandrescu wrote:It may be the case you're using different definitions of the term "contextual keyword". Far as I can tell you want the identifier "nogc" be recognized in certain places by the compiler as special, and otherwise just not be special at all. That's a contextual keyword. If that's the case you were well understood by both Walter and myself. I happen to recognize the merit of contextual keyword in general, but Walter has a stronger opposition to it. It doesn't seem to me this particular application is compelling enough to warrant the precedent. -- AndreiOk now we're getting somewhere. I guess the next thing I'd like to ask is what is the argument against having a word be a function attribute in one instance and a regular identifier in another? I would think the reason would be it could make the grammar ambiguous. That's why I proposed it only be valid on the right hand side of the function to guarantee it doesn't introduce any ambiguity. Other then that, I don't see any reason why it's a bad thing. It doesn't make the syntax more complicated, it doesn't maker it harder to parse, I just don't see why its bad. Note: keep in mind...I'm not asking why it's bad to have a keyword (recognized as a keyword by the lexer) also be an identifier, I'm asking why it's bad to have a function attribute also be an identifier.
Jan 28 2015
Jonathan Marler via Digitalmars-d pÃÅ¡e v St 28. 01. 2015 v 19:13 +0000:On Wednesday, 28 January 2015 at 19:04:50 UTC, Andrei Alexandrescu wrote:Thats not possible: safe { void some func() // now valid } safe: void some func() // now valid safe { void some func() // could not be valid } safe: void some func() // could not be valid So you need more places where keyword needs to be contextual keyword And this is a path I am not sure we want to go.It may be the case you're using different definitions of the term "contextual keyword". Far as I can tell you want the identifier "nogc" be recognized in certain places by the compiler as special, and otherwise just not be special at all. That's a contextual keyword. If that's the case you were well understood by both Walter and myself. I happen to recognize the merit of contextual keyword in general, but Walter has a stronger opposition to it. It doesn't seem to me this particular application is compelling enough to warrant the precedent. -- AndreiOk now we're getting somewhere. I guess the next thing I'd like to ask is what is the argument against having a word be a function attribute in one instance and a regular identifier in another? I would think the reason would be it could make the grammar ambiguous. That's why I proposed it only be valid on the right hand side of the function to guarantee it doesn't introduce any ambiguity. Other then that, I don't see any reason why it's a bad thing. It doesn't make the syntax more complicated, it doesn't maker it harder to parse, I just don't see why its bad.
Jan 28 2015
On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak wrote:None of those cases would valid. Non-Keyword attributes without a ' ' must be on the right hand side of the function parameters. void some func(); // some is not a keyword, so it is invalidI would think the reason would be it could make the grammar ambiguous. That's why I proposed it only be valid on the right hand side of the function to guarantee it doesn't introduce any ambiguity. Other then that, I don't see any reason why it's a bad thing. It doesn't make the syntax more complicated, it doesn't maker it harder to parse, I just don't see why its bad.Thats not possible: safe { void some func() // now valid } safe: void some func() // now valid safe { void some func() // could not be valid } safe: void some func() // could not be valid So you need more places where keyword needs to be contextual keyword And this is a path I am not sure we want to go.
Jan 28 2015
Jonathan Marler via Digitalmars-d pÃÅ¡e v St 28. 01. 2015 v 19:33 +0000:On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak wrote:Typo I mean some_funcNone of those cases would valid. Non-Keyword attributes without a ' ' must be on the right hand side of the function parameters. void some func(); // some is not a keyword, so it is invalidI would think the reason would be it could make the grammar ambiguous. That's why I proposed it only be valid on the right hand side of the function to guarantee it doesn't introduce any ambiguity. Other then that, I don't see any reason why it's a bad thing. It doesn't make the syntax more complicated, it doesn't maker it harder to parse, I just don't see why its bad.Thats not possible: safe { void some func() // now valid } safe: void some func() // now valid safe { void some func() // could not be valid } safe: void some func() // could not be valid So you need more places where keyword needs to be contextual keyword And this is a path I am not sure we want to go.
Jan 28 2015
On Wednesday, 28 January 2015 at 21:37:02 UTC, Daniel Kozak wrote:Jonathan Marler via Digitalmars-d pÃÅ¡e v St 28. 01. 2015 v 19:33 +0000:Oh ok. Then I'm not sure what your trying to say with your examples. The proposal is that you could only omit the ' ' symbol if the word appeared after the function parameters. safe void foo(); // STILL NOT VALID void foo() safe; // NOW VALID If it comes before, then you still need the ' '. safe void foo(); // STILL VALID (no change), however, // this usage would be discouraged Your examples do bring up a usage I hadn't thought of though. It would be a bit odd for newcomers to use "safe" without an ' ' in one case and then have to include the ' ' another case (the example you provided). This makes it less appealing. Either way, I don't think it matters since the proposal isn't acceptable for a different reason, the leadership doesn't like the same words to be used as function attributes sometimes and identifiers other times.On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak wrote:Typo I mean some_funcNone of those cases would valid. Non-Keyword attributes without a ' ' must be on the right hand side of the function parameters. void some func(); // some is not a keyword, so it is invalidI would think the reason would be it could make the grammar ambiguous. That's why I proposed it only be valid on the right hand side of the function to guarantee it doesn't introduce any ambiguity. Other then that, I don't see any reason why it's a bad thing. It doesn't make the syntax more complicated, it doesn't maker it harder to parse, I just don't see why its bad.Thats not possible: safe { void some func() // now valid } safe: void some func() // now valid safe { void some func() // could not be valid } safe: void some func() // could not be valid So you need more places where keyword needs to be contextual keyword And this is a path I am not sure we want to go.
Jan 28 2015
On 1/28/2015 1:46 PM, Jonathan Marler wrote:Your examples do bring up a usage I hadn't thought of though. It would be a bit odd for newcomers to use "safe" without an ' ' in one case and then have to include the ' ' another case (the example you provided). This makes it less appealing. Either way, I don't think it matters since the proposal isn't acceptable for a different reason, the leadership doesn't like the same words to be used as function attributes sometimes and identifiers other times.Good language design has redundancy in it. Often people see the redundancy, and advocate removing it as noise. But the redundancy has a valuable purpose - diagnosing of errors, and offering suggestions for fixing the errors. If there was no redundancy in the language, every random sequence of bytes would be a valid program. For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially. So consider: void func() safe T = 7; With your proposal, an error isn't discovered until the '=' is found. But what kind of error is it? Did the user mean: void func() safe; void func() safe T; void func(); safe T = 7; Even for humans it can be hard to discern what the user meant it to be, especially if he also is not using whitespace formatting as further redundancy. Keywords and punctuation form "anchors" that both humans, syntax highlighters, and parsers use to add redundancy and "synchronization points" (which enable error recovery, such as "give up on the current AST and scan forward to find the next anchor and start afresh").
Jan 28 2015
On Wednesday, 28 January 2015 at 22:28:08 UTC, Walter Bright wrote:For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially.That explains why new languages make ";" optional, or wait... Could it be that the language designers of new languages have realized that using ";" for discrimination on line endings is fragile and tedious. Could it be that new languages define grammars that are more robust than the one used by C? Like Go? Or to put it succinctly: If legibility is dependent on a little fly shit on the screen, then the language design sure isn't optimal.
Jan 28 2015
On Wednesday, 28 January 2015 at 22:44:45 UTC, Ola Fosheim Grøstad wrote:On Wednesday, 28 January 2015 at 22:28:08 UTC, Walter Bright wrote:Counter example: Rust. Of course, Rust isn't the epitome of readability.For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially.That explains why new languages make ";" optional, or wait... Could it be that the language designers of new languages have realized that using ";" for discrimination on line endings is fragile and tedious. Could it be that new languages define grammars that are more robust than the one used by C? Like Go?Or to put it succinctly: If legibility is dependent on a little fly shit on the screen, then the language design sure isn't optimal.
Jan 29 2015
On 28/01/2015 22:44, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang gmail.com>" wrote:Could it be that new languages define grammars that are more robust than the one used by C? Like Go?We're not going to significantly change the structural syntax of D, so it doesn't seem that your argument is particularly relevant here.
Jan 29 2015
On 2015-01-28 at 23:27, Walter Bright wrote:Good language design has redundancy in it. Often people see the redundancy, and advocate removing it as noise. But the redundancy has a valuable purpose - diagnosing of errors, and offering suggestions for fixing the errors. If there was no redundancy in the language, every random sequence of bytes would be a valid program.I'm quite sure I have read this very same thing not so long ago. :)
Jan 28 2015
On 1/28/15 3:14 PM, FG wrote:On 2015-01-28 at 23:27, Walter Bright wrote:We should add that stuff and what Jonathan wrote to the FAQ on the wiki. -- AndreiGood language design has redundancy in it. Often people see the redundancy, and advocate removing it as noise. But the redundancy has a valuable purpose - diagnosing of errors, and offering suggestions for fixing the errors. If there was no redundancy in the language, every random sequence of bytes would be a valid program.I'm quite sure I have read this very same thing not so long ago. :)
Jan 28 2015
On 1/28/2015 3:14 PM, FG wrote:On 2015-01-28 at 23:27, Walter Bright wrote:I repeat it regularly! It's one of those things that one only learns the hard way, because the subtleties of it are not at all obvious. It's one of the mistakes that inexperienced language designers make again and again. One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?)Good language design has redundancy in it. Often people see the redundancy, and advocate removing it as noise. But the redundancy has a valuable purpose - diagnosing of errors, and offering suggestions for fixing the errors. If there was no redundancy in the language, every random sequence of bytes would be a valid program.I'm quite sure I have read this very same thing not so long ago. :)
Jan 28 2015
On 2015-01-29 01:19, Walter Bright wrote:One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?)Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers. -- /Jacob Carlborg
Jan 29 2015
On Thursday, 29 January 2015 at 14:00:16 UTC, Jacob Carlborg wrote:On 2015-01-29 01:19, Walter Bright wrote:And it is so bad when the codebase grows that people are willing to switch to Node.js (!)One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?)Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers.
Jan 29 2015
On Thursday, 29 January 2015 at 17:17:44 UTC, deadalnix wrote:On Thursday, 29 January 2015 at 14:00:16 UTC, Jacob Carlborg wrote:That is so yesterday, they are now either on Go or Clojure.On 2015-01-29 01:19, Walter Bright wrote:And it is so bad when the codebase grows that people are willing to switch to Node.js (!)One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?)Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers.
Jan 29 2015
On 2015-01-29 18:17, deadalnix wrote:And it is so bad when the codebase grows that people are willing to switch to Node.js (!)And still people are using it successfully. -- /Jacob Carlborg
Jan 29 2015
On Thursday, 29 January 2015 at 19:49:58 UTC, Jacob Carlborg wrote:On 2015-01-29 18:17, deadalnix wrote:Yes, my point is that there is tradeof. This is easy to build something fast in ruby, but this becomes unmaintainable at scale. I'm not sure this is the tradeof we want in D.And it is so bad when the codebase grows that people are willing to switch to Node.js (!)And still people are using it successfully.
Jan 29 2015
On Thu, 29 Jan 2015 17:17:44 +0000, deadalnix wrote:On Thursday, 29 January 2015 at 14:00:16 UTC, Jacob Carlborg wrote:'cause they think that javascript is kind of magic that will turn their=20 shitcode to great code. what they didn't realise is that shitcode lives=20 in their heads, not in languages.=On 2015-01-29 01:19, Walter Bright wrote:=20 And it is so bad when the codebase grows that people are willing to switch to Node.js (!)One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?)Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers.
Jan 29 2015
On 1/29/2015 6:00 AM, Jacob Carlborg wrote:On 2015-01-29 01:19, Walter Bright wrote:"Some languages have started out with the implicit declaration behavior, but as they matured they provided an option to disable it (e.g. Perl's "use strict" or Visual Basic's "Option Explicit")." -- http://en.wikipedia.org/wiki/Declaration_(computer_programming)#Variables Ruby also has monkey patching, another misfeature. Even so, lots of languages survive execrable features if they are counterbalanced by more desirable one.One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?)Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers.
Jan 29 2015
On Thursday, January 29, 2015 13:47:47 Walter Bright via Digitalmars-d wrote:Even so, lots of languages survive execrable features if they are counterbalanced by more desirable one.C! - Jonathan M Davis
Jan 29 2015
On 2015-01-29 22:47, Walter Bright wrote:Ruby also has monkey patching, another misfeature.It works great, have you actually used it? The entire Rails plugin system is built around monkey patching. It's far more successful than any D project. -- /Jacob Carlborg
Jan 30 2015
On Friday, 30 January 2015 at 09:21:17 UTC, Jacob Carlborg wrote:On 2015-01-29 22:47, Walter Bright wrote:I have to agree with Jacob. It's an extremely powerful tool. It's used for things that D would use templating, introspection, CTFE and mixins for. Of course, each of these has its disadvantages, but that doesn't make them misfeatures at all. Unlike real misfeatures, the chance that someone uses them (or monkey patching) by accident and unintentionally is low.Ruby also has monkey patching, another misfeature.It works great, have you actually used it? The entire Rails plugin system is built around monkey patching. It's far more successful than any D project.
Jan 30 2015
On 2015-01-28 23:27, Walter Bright wrote:For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially. So consider: void func() safe T = 7; With your proposal, an error isn't discovered until the '=' is found.A good language design that doesn't require the ; statement terminator would recognize "void func()" as a valid statement and implicit add ;. Scan the line, if a valid language construct has been seen at the end of the line, insert a ;, if not continue to the next line. That works in many languages. -- /Jacob Carlborg
Jan 29 2015
On Thursday, 29 January 2015 at 13:58:52 UTC, Jacob Carlborg wrote:A good language design that doesn't require the ; statement terminator would recognize "void func()" as a valid statement and implicit add ;. Scan the line, if a valid language construct has been seen at the end of the line, insert a ;, if not continue to the next line. That works in many languages.Tells me what this function returns in javascript : function foo() { return { foo: "bar", } } Yes, you guessed right, it returns undefined. Ho you didn't ? What a surprise !
Jan 29 2015
On Thu, 29 Jan 2015 14:58:51 +0100, Jacob Carlborg wrote:On 2015-01-28 23:27, Walter Bright wrote: =20this never worked good. see deadalnix. or: foo.bar .zed is `.zed` a chained call or free call? oh, well, build symbol table to=20 find that? and what if we have free function `zed` and a method `zed`? there can be alot of such samples. implicit `;` never worked right in=20 grammars that allows arbitrary newlines. such grammars requires explicit=20 "end-of-sentence" signs to be parsable without ambiguities on almost each=20 code line.=For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially. So consider: void func() safe T =3D 7; With your proposal, an error isn't discovered until the '=3D' is found.=20 A good language design that doesn't require the ; statement terminator would recognize "void func()" as a valid statement and implicit add ;. Scan the line, if a valid language construct has been seen at the end of the line, insert a ;, if not continue to the next line. That works in many languages.
Jan 29 2015
On 2015-01-29 22:02, ketmar wrote:this never worked good. see deadalnix. or: foo.bar .zedIn Ruby ".zed" is not valid code, so in Ruby it means: foo.bar.zed; In D it, with my rules, it would mean: foo.bar; .zed; In D you would need to write: foo.bar. zed -- /Jacob Carlborg
Jan 30 2015
On 1/29/2015 5:58 AM, Jacob Carlborg wrote:On 2015-01-28 23:27, Walter Bright wrote:Oh, I know it can be made to work. That wasn't my point, which I shall repeat: "error message clarity, recovery, and the correct identification of the location of the error degrades substantially" Notice that your comment is still relying on remaining redundancy to try to figure out where the ; is supposed to go.For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially. So consider: void func() safe T = 7; With your proposal, an error isn't discovered until the '=' is found.A good language design that doesn't require the ; statement terminator would recognize "void func()" as a valid statement and implicit add ;. Scan the line, if a valid language construct has been seen at the end of the line, insert a ;, if not continue to the next line. That works in many languages.
Jan 29 2015
On 2015-01-29 22:50, Walter Bright wrote:"error message clarity, recovery, and the correct identification of the location of the error degrades substantially"I never had problems with the error messages in Ruby. But I do have had problems with them in D. Example: int a = 3 int b = 4; The compiler will complain there's a missing semicolon on line 4 in front of "int". The user has most likely forget to add the semicolon at the end of the first line.Notice that your comment is still relying on remaining redundancy to try to figure out where the ; is supposed to go.You need some kind of separation between the statements. In Ruby a newline works as a statement separator. -- /Jacob Carlborg
Jan 30 2015
On Friday, 30 January 2015 at 09:27:09 UTC, Jacob Carlborg wrote:You need some kind of separation between the statements. In Ruby a newline works as a statement separator.I think Go actually injects ";" in the lexer on tokens that can end statements if the token is followed by newline. Sounds crazy, but it works for that grammar.
Jan 30 2015
On 1/30/2015 1:27 AM, Jacob Carlborg wrote:In Ruby a newline works as a statement separator.Making it not an example of what I was talking about.
Jan 30 2015
On Wednesday, 28 January 2015 at 19:33:32 UTC, Jonathan Marler wrote:On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak wrote:Then I'm afraid the proposal is pointless :-( The goal AIUI is to make the language more consistent. If we can't use the new syntax everywhere (and later get rid of the old one), we can't achieve that.None of those cases would valid. Non-Keyword attributes without a ' ' must be on the right hand side of the function parameters.I would think the reason would be it could make the grammar ambiguous. That's why I proposed it only be valid on the right hand side of the function to guarantee it doesn't introduce any ambiguity. Other then that, I don't see any reason why it's a bad thing. It doesn't make the syntax more complicated, it doesn't maker it harder to parse, I just don't see why its bad.Thats not possible: safe { void some func() // now valid } safe: void some func() // now valid safe { void some func() // could not be valid } safe: void some func() // could not be valid So you need more places where keyword needs to be contextual keyword And this is a path I am not sure we want to go.
Jan 29 2015
On 1/28/15 11:13 AM, Jonathan Marler wrote:On Wednesday, 28 January 2015 at 19:04:50 UTC, Andrei Alexandrescu wrote:I'd say we just drop it. It's a waste of time to talk about it. There's no proof on why the idea isn't accepted, and there's no need for one. I just wrote out of empathy. As a newcomer to language communities (including this one) I've had literally dozens of ideas on how they can be improved. All looked great to myself at the time, and of them some felt actually unassailably good. So good, in fact, that I'd attach a sense of importance to them and was convinced that explaining and advertising them well was essential, and that opponents didn't really understand their advantages. For the most part they were in reality weak ideas of a n00b, ideas of greatly overstated merit, and acknowledging that has made me better. AndreiIt may be the case you're using different definitions of the term "contextual keyword". Far as I can tell you want the identifier "nogc" be recognized in certain places by the compiler as special, and otherwise just not be special at all. That's a contextual keyword. If that's the case you were well understood by both Walter and myself. I happen to recognize the merit of contextual keyword in general, but Walter has a stronger opposition to it. It doesn't seem to me this particular application is compelling enough to warrant the precedent. -- AndreiOk now we're getting somewhere. I guess the next thing I'd like to ask is what is the argument against having a word be a function attribute in one instance and a regular identifier in another? I would think the reason would be it could make the grammar ambiguous. That's why I proposed it only be valid on the right hand side of the function to guarantee it doesn't introduce any ambiguity. Other then that, I don't see any reason why it's a bad thing. It doesn't make the syntax more complicated, it doesn't maker it harder to parse, I just don't see why its bad. Note: keep in mind...I'm not asking why it's bad to have a keyword (recognized as a keyword by the lexer) also be an identifier, I'm asking why it's bad to have a function attribute also be an identifier.
Jan 28 2015
On Wednesday, 28 January 2015 at 19:46:33 UTC, Andrei Alexandrescu wrote:I'd say we just drop it. It's a waste of time to talk about it. There's no proof on why the idea isn't accepted, and there's no need for one. I just wrote out of empathy. As a newcomer to language communities (including this one) I've had literally dozens of ideas on how they can be improved. All looked great to myself at the time, and of them some felt actually unassailably good. So good, in fact, that I'd attach a sense of importance to them and was convinced that explaining and advertising them well was essential, and that opponents didn't really understand their advantages. For the most part they were in reality weak ideas of a n00b, ideas of greatly overstated merit, and acknowledging that has made me better. AndreiMaybe this is a weak proposal but I don't know how to realize that unless I ask the people who oppose it to explain themselves. How else will I learn? My proposal would be a nice feature but like I've said, it's not a huge deal. There's so many more important things to worry about. However, I don't think it's unreasonable to ask someone to explain why they do or don't like something. I believe I'm being pragmatic here. What's frustrating to me isn't that my proposal wasn't accepted, its that it was so hard to communicate over such a simple issue. It took so much time and everything had to be said over and over again. But at least I have a reason why it was rejected. Now I can tell people, the leadership in D does not like to have a word be a function attribute in one place and normal identifier in another place. I would like to understand why the leadership does not want this but since there are more important things, and time is a finite resource, consider this issue "let go". Thanks Andrei, I appreciate your input on this. Now if you can get that list of high priority issues out so I can know what I should be working on that would be great!
Jan 28 2015
On Wednesday, 28 January 2015 at 20:11:32 UTC, Jonathan Marler wrote:Thanks Andrei, I appreciate your input on this. Now if you can get that list of high priority issues out so I can know what I should be working on that would be great!+1.000.000.000 (Finally an empathic confession for betterment!)
Jan 28 2015
On Wednesday, 28 January 2015 at 20:11:32 UTC, Jonathan Marler wrote:Maybe this is a weak proposal but I don't know how to realize that unless I ask the people who oppose it to explain themselves. How else will I learn?I also think arguing is a very good way to learn too - but please don't forget that Walter time is extremely precious and if understanding has not been achieved quickly enough it may be better to drop the discussion for a while. Later more data may appear, context may change, Walter opinion may change (that happens!) and another small iteration will yield much more productive results.
Jan 28 2015
On Wednesday, 28 January 2015 at 20:11:32 UTC, Jonathan Marler wrote:Now if you can get that list of high priority issues out so I can know what I should be working on that would be great!It would be nice to know the priorities of the leadership, but, if you have the skills to hack the compiler, bugzilla is the place to start earning one's wings and influence. I would love it you could fix this (these) bugs. https://issues.dlang.org/show_bug.cgi?id=13372 https://issues.dlang.org/show_bug.cgi?id=12496 And I'm sure bug fixes are already pre-approved. Mike
Jan 28 2015
On Wednesday, 28 January 2015 at 18:37:48 UTC, Jonathan Marler wrote:On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei Alexandrescu wrote:I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive. Walter said that `exit`, `C++`, i.e. `scope(exit)`, `extern (C++)` etc. were never keywords, but I disagree. They are indeed context sensitive keywords. They have wisely been kept to a minimum. They are just confusing to reason about, except in the most strictly confined places, where they are now. I think that's why they're out of the question. They have wisely been kept to a minimum.On 1/28/15 10:19 AM, Jonathan Marler wrote:You can follow this thread: http://forum.dlang.org/post/fxbqqecgqdhrepxsjnep forum.dlang.org I explained my proposal 3 or 4 times but each time Walter seemed to be misunderstanding my proposal saying it was going to create "context-sensitive" tokens and so he would immediately dismiss it. I tried to understand what he meant by "context-sensitive" tokens because my proposal didn't have anything to do with them (at least my definition of them), but even after he defined them my proposal clearly does not create them. Walter "[A context-sensitive token is] A keyword in one context and an identifier in another" Anyway, I'll restate my proposal again: 1. Modify the SYNTAX of function to allow it to be decorated with IDENTIFIER tokens on the right hand side void foo() x; // valid SYNTAX (note: has not semantic meaning) void foo() safe; // valid SYNTAX and valid SEMANTICS 2. Modify the code that interprets the syntax tree to recognize these identifiers as function attributes. A simple solution that would allow us to standardize where we put the function attributes and allow us to remove the ' ' character from all non-keyword function attributes. Seems like a no-brainer to me.On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:Was that the proposal leading to this state of affairs (quoting from your post on 2015/01/26 16:05 PST?On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:I would but Walter said no. I'm certain he misunderstood my proposal and I tried to explain it to him but I couldn't get him to address it.PLUS, this would be very simple to implement!Then I recommend you submit a pull request. MikeHere's what would change ----------------------------------------------------------------- void myfunc() nogc; // VALID (Only if this proposal is accepted) void myfunc() safe; // VALID (Only if this proposal is accepted) Here's what WOULD NOT change ----------------------------------------------------------------- nogc myfunc(); // STILL INVALID: invalid unless it can be verified // that this wouldn't result in ambiguity // in the grammar void myfunc() nogc; // STILL VALID (no change) nogc myfunc(); // STILL VALID (no change)Andrei
Jan 28 2015
On Wednesday, 28 January 2015 at 18:54:29 UTC, Zach the Mystic wrote:I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive. Walter said that `exit`, `C++`, i.e. `scope(exit)`, `extern (C++)` etc. were never keywords, but I disagree. They are indeed context sensitive keywords. They have wisely been kept to a minimum. They are just confusing to reason about, except in the most strictly confined places, where they are now. I think that's why they're out of the question. They have wisely been kept to a minimum.This is actually a valid argument against my proposal. Thank you! lol. I don't agree with it but at least it's valid :) Your reasoning depends on how you define a keyword. You seem to be defining a keyword in terms of an identifier that is recognized by the compiler to have a special meaning. I define a keyword as a word that the lexer recognizes as a keyword token. I see what you mean by saying that the word is a function attribute in one place and an identifier in another. But what's wrong with that? if I define a struct named mystruct...I could declare one like this: mystruct mystruct; The first appearance is a type and the second is an identifier. I'm sure there are many examples of this in the language. Anyway, I disagree with your conclusion, however, I agree that this could be a concern.
Jan 28 2015
On Wednesday, 28 January 2015 at 19:07:59 UTC, Jonathan Marler wrote:On Wednesday, 28 January 2015 at 18:54:29 UTC, Zach the Mystic wrote:It's utterly confusing is the problem. I would consider it a great disservice to all D programmers to allow this. Just because you can doesn't mean you should. Walter has emphasize there is absolutely no shortage of valid words. There is however, a shortage of what a programmer can keep organized in his head. That's the shortage you should prioritize, sir. I'm not sure how to emphasize this anymore. We may just have to agree to disagree.I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive. Walter said that `exit`, `C++`, i.e. `scope(exit)`, `extern (C++)` etc. were never keywords, but I disagree. They are indeed context sensitive keywords. They have wisely been kept to a minimum. They are just confusing to reason about, except in the most strictly confined places, where they are now. I think that's why they're out of the question. They have wisely been kept to a minimum.This is actually a valid argument against my proposal. Thank you! lol. I don't agree with it but at least it's valid :) Your reasoning depends on how you define a keyword. You seem to be defining a keyword in terms of an identifier that is recognized by the compiler to have a special meaning. I define a keyword as a word that the lexer recognizes as a keyword token. I see what you mean by saying that the word is a function attribute in one place and an identifier in another. But what's wrong with that? if I define a struct named mystruct...I could declare one like this: mystruct mystruct;
Jan 28 2015
On Wednesday, 28 January 2015 at 20:12:03 UTC, Zach the Mystic wrote:because you can doesn't mean you should. Walter has emphasize there is absolutely no shortage of valid words.can you spot the contradiction ?
Jan 28 2015
On Wednesday, 28 January 2015 at 20:12:03 UTC, Zach the Mystic wrote:It's utterly confusing is the problem. I would consider it a great disservice to all D programmers to allow this. Just because you can doesn't mean you should. Walter has emphasize there is absolutely no shortage of valid words. There is however, a shortage of what a programmer can keep organized in his head. That's the shortage you should prioritize, sir. I'm not sure how to emphasize this anymore. We may just have to agree to disagree.I don't think this is confusing: void foo() safe { bool safe = false; } Using "safe" as both a function attribute and an identifier doesn't seem confusing to me, however, it appears the leadership agrees with you so I submit. Let's consider this resolved and move on to better more interesting things:) I appreciate you taking the time to voice your opinion and helping me understand the arguments against this idea.
Jan 28 2015
On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler wrote:Using "safe" as both a function attribute and an identifier doesn't seem confusing to me, however, it appears the leadership agrees with you so I submit.Now you disappoint me. Your rebellious mindset has been poisoned by the Evil Spirit of Gn sh. Thou shalt not give up yer own freedom to choose yer own identifiers for heavens sake. Maintain yer own parse.c like everybody else!!! That's what ketmar and I do. It is known as Free Software Freedom.
Jan 28 2015
On Wednesday, 28 January 2015 at 22:36:13 UTC, Ola Fosheim Grøstad wrote:On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler wrote:Lol, you guys are hilarious. There's D1, D2 and now DOla and DKetmar!Using "safe" as both a function attribute and an identifier doesn't seem confusing to me, however, it appears the leadership agrees with you so I submit.Now you disappoint me. Your rebellious mindset has been poisoned by the Evil Spirit of Gn sh. Thou shalt not give up yer own freedom to choose yer own identifiers for heavens sake. Maintain yer own parse.c like everybody else!!! That's what ketmar and I do. It is known as Free Software Freedom.
Jan 28 2015
On Wed, 28 Jan 2015 22:39:01 +0000, Jonathan Marler wrote:On Wednesday, 28 January 2015 at 22:36:13 UTC, Ola Fosheim Gr=C3=B8stad wrote:not "DKetmar", it's titled "Aliced". ;-)=On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler wrote:=20 Lol, you guys are hilarious. There's D1, D2 and now DOla and DKetmar!Using "safe" as both a function attribute and an identifier doesn't seem confusing to me, however, it appears the leadership agrees with you so I submit.Now you disappoint me. Your rebellious mindset has been poisoned by the Evil Spirit of Gn sh. Thou shalt not give up yer own freedom to choose yer own identifiers for heavens sake. Maintain yer own parse.c like everybody else!!! That's what ketmar and I do. It is known as Free Software Freedom.
Jan 28 2015
On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler wrote:On Wednesday, 28 January 2015 at 20:12:03 UTC, Zach the Mystic wrote:I invested the time because you took a very polite and civil tone. ;) I'm glad I was able to find a way of wording it that helped. I'm also glad Walter was able to follow it up with an even better reasoning which speaks from deep experience, which I could not have done. Let's move on!It's utterly confusing is the problem. I would consider it a great disservice to all D programmers to allow this. Just because you can doesn't mean you should. Walter has emphasize there is absolutely no shortage of valid words. There is however, a shortage of what a programmer can keep organized in his head. That's the shortage you should prioritize, sir. I'm not sure how to emphasize this anymore. We may just have to agree to disagree.I don't think this is confusing: void foo() safe { bool safe = false; } Using "safe" as both a function attribute and an identifier doesn't seem confusing to me, however, it appears the leadership agrees with you so I submit. Let's consider this resolved and move on to better more interesting things:) I appreciate you taking the time to voice your opinion and helping me understand the arguments against this idea.
Jan 28 2015
On Thursday, 29 January 2015 at 03:14:10 UTC, Zach the Mystic wrote:helped. I'm also glad Walter was able to follow it up with an even better reasoning which speaks from deep experience, which I could not have done. Let's move on!Indeed, Walter has some deep reasoning ENTIRELY based on personal experience. Unfortunately it totally lacks theoretical backing and shows a complete disregard for how usability evaluation is done. Other popular languages, who have users that do not complain about language syntax, are obviously wrong because they eschew Walter's personal deep reasoned experience. These users must be delusional and clueless for being happy with a syntax that is obviously flawed for not providing redundant noise that improves usability! While D, who have few users of which a fair share keep complaining about the syntax, is beyond critique with an ever expanding feature set and an increasing pile of reserved words that prevent library authors from implementing the most common standard on this planet. Here is the crux: nobody forces people who don't want to use "body" as an identifier to use it, but that is not a good argument for preventing everybody else from using it as an identifier! D is a practically impractical language until it provides: 1. feature freeze 2. semantic specification 3. clean slate syntax upgrade D is a hobby language and is loosing more talent than it should for not following a reasonable trajectory. 16 years in the making, still no stable release.
Jan 29 2015
On Thursday, 29 January 2015 at 10:22:13 UTC, Ola Fosheim Grøstad wrote:Indeed, Walter has some deep reasoning ENTIRELY based on personal experience. Unfortunately it totally lacks theoretical backing and shows a complete disregard for how usability evaluation is done. Other popular languages, who have users that do not complain about language syntax, are obviously wrong because they eschew Walter's personal deep reasoned experience. These users must be delusional and clueless for being happy with a syntax that is obviously flawed for not providing redundant noise that improves usability! While D, who have few users of which a fair share keep complaining about the syntax, is beyond critique with an ever expanding feature set and an increasing pile of reserved words that prevent library authors from implementing the most common standard on this planet. Here is the crux: nobody forces people who don't want to use "body" as an identifier to use it, but that is not a good argument for preventing everybody else from using it as an identifier! D is a practically impractical language until it provides: 1. feature freeze 2. semantic specification 3. clean slate syntax upgrade D is a hobby language and is loosing more talent than it should for not following a reasonable trajectory. 16 years in the making, still no stable release.In the Mythical Man Month, Brooks advises for a single person responsible for architecture, or a dynamic duo (this is exactly what we are with Walter and Andrei). This role was rediscovered as "product owner" in Agile settings. Strong leadership and saying "no" more often that people would like is a constant among good projects. I also made D proposals back in the days and they were crap proposals (literally). You, personally, want syntax changes AND feature freeze. Nobody would use a language whose leaders have said yes to the ideas of the every abusive internet users out there.
Jan 29 2015
On Thursday, 29 January 2015 at 10:50:49 UTC, ponce wrote:In the Mythical Man Month, Brooks advises for a single person responsible for architecture, or a dynamic duo (this is exactly what we are with Walter and Andrei).You mean like Batman? I don't feel like discussing system development principles with you if you think the "dynamic duo" is anywhere near following sound software engineering principles. It is not a fun topic to teach (yes, I have done that).This role was rediscovered as "product owner" in Agile settings. Strong leadership and saying "no" more often that people would like is a constant among good projects.The only thing that truly matters is that you have a plan and a reasonable process to back it up. Leadership is about facilitating the process. A role is not a person, it is backing a task that to be fulfilled to facilitate the process in a predictable and orderly fashion.I also made D proposals back in the days and they were crap proposals (literally). You, personally, want syntax changes AND feature freeze.I personally don't think it is reasonable for Walter and Andrei to present D as a tool that is suitable for production. If it is, then they have to fess up to massive critique. Take a look at dlang.org, where does it say "experimental language"? It used to say "beta", which actually should have been "alpha"... I personally only want D to follow sound engineering principles. I personally don't want syntax changes or feature freeze, since it won't help without a solid process to back it up.Nobody would use a language whose leaders have said yes to the ideas of the every abusive internet users out there.I think it is abusive and dishonest to present a language as ready for use when it nowhere near a stable release. I've previously requested that they actually do language design by writing up a spec for where D is heading, so that people can make up their mind and decide to provide "implementation power" if they like the presented outcome. Without a clear horizon, it makes no sense to participate unless you have it as a hobby. That slows down progress. That is what makes Rust and Go winners and D a stagnation. What I suggest is the best for D is: 1. Feature freeze. 2. Fix semantics/refactor compiler internals. 3. Fix syntax to be mainstream friendly. In that order. I have no hope that it will happen without a major restructuring of the process. I'm totally with ketmar on that front.
Jan 29 2015
On 2015-01-28 20:07, Jonathan Marler wrote:You seem to be defining a keyword in terms of an identifier that is recognized by the compiler to have a special meaning.By that definition basically all declarations in the object module is a keyword :) -- /Jacob Carlborg
Jan 29 2015
On Wednesday, 28 January 2015 at 18:54:29 UTC, Zach the Mystic wrote:I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere.That's a reserved word. A reserved word cannot be used as an identifier. A keyword is a phrase that has a special semantic meaning in a context. That does not make it context sensitive if the language can be recognized by a context free grammar... Confusing? I guess... Some languages would allow this: "if if = 0 then ... fi", it is not context sensitive because it can be recognized by a CFG. The first "if" is a keyword. The second "if" is an identifier.
Jan 28 2015
On Wed, 28 Jan 2015 18:54:27 +0000, Zach the Mystic wrote:I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive.yep. that is "slave to the machine" approach. i don't really care how=20 hard machine should work to understand what i want. ;-) i.e. i can't see why i have to deal with problems of compiler/tool/editor=20 author. it's easy -- at least in this case -- for human to see where=20 keywords are keywords. machine can see that too with some analysis. yet=20 somehow situation is horribly reversed: instead of machine helping me to=20 do what i want, that's me who must obey the machine orders and do the=20 work that machine can do for me.=
Jan 28 2015
On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:On Wed, 28 Jan 2015 18:54:27 +0000, Zach the Mystic wrote:That is a retarded mindset. It is not about how hard it is for the machine, but for tool writer. I know many people look down on java, but quite frankly, the tooling is just way better than pretty much anything else. One could argue this is because of corporate support, but other languages like C++ also have important corporate support. And still, C++ tooling mostly suck. Honestly, pretty anything except The problem of the tool writer is your problem, because any tool that isn't written is work you need to yourself. And then who's the slave to the machine ?I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive.yep. that is "slave to the machine" approach. i don't really care how hard machine should work to understand what i want. ;-) i.e. i can't see why i have to deal with problems of compiler/tool/editor author. it's easy -- at least in this case -- for human to see where keywords are keywords. machine can see that too with some analysis. yet somehow situation is horribly reversed: instead of machine helping me to do what i want, that's me who must obey the machine orders and do the work that machine can do for me.
Jan 28 2015
On Wed, 28 Jan 2015 23:36:29 +0000, deadalnix wrote:On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:and there are at least 4 available codebases for writing tools. for C++=20 there is DMD frontend. for D there is dscanner, magicport and SDC. yet=20 instead of thinking how all that code can help me and made my life=20 better, i should think how making my life harder will help to write great=20 tools somewhere in the future. that is what i call "retarded mindset".=On Wed, 28 Jan 2015 18:54:27 +0000, Zach the Mystic wrote:=20 That is a retarded mindset. It is not about how hard it is for the machine, but for tool writer. =20 I know many people look down on java, but quite frankly, the tooling is just way better than pretty much anything else. One could argue this is because of corporate support, but other languages like C++ also have important corporate support. And still, C++ tooling mostly suck. =20 The problem of the tool writer is your problem, because any tool that isn't written is work you need to yourself. And then who's the slave to the machine ?I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive.yep. that is "slave to the machine" approach. i don't really care how hard machine should work to understand what i want. ;-) i.e. i can't see why i have to deal with problems of compiler/tool/editor author. it's easy -- at least in this case -- for human to see where keywords are keywords. machine can see that too with some analysis. yet somehow situation is horribly reversed: instead of machine helping me to do what i want, that's me who must obey the machine orders and do the work that machine can do for me.
Jan 28 2015
On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:On Wed, 28 Jan 2015 18:54:27 +0000, Zach the Mystic wrote:I take it you also don't care if your IDE lags for 5 seconds every time you type a character?I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive.yep. that is "slave to the machine" approach. i don't really care how hard machine should work to understand what i want. ;-)i.e. i can't see why i have to deal with problems of compiler/tool/editor author. it's easy -- at least in this case -- for human to see where keywords are keywords. machine can see that too with some analysis.I'm a tool writer. If I have enough problems, I don't build the tool. The problem is now your problem. You know what else is easy for humans? Image and audio processing and knowing how to walk. Things that are easy for machines are hard for humans. Things that are easy for humans are hard for machines.yet somehow situation is horribly reversed: instead of machine helping me to do what i want, that's me who must obey the machine orders and do the work that machine can do for me.If it really is work that the machine can do for you, why haven't you made the machine do it?
Jan 28 2015
On Thu, 29 Jan 2015 00:03:51 +0000, Brian Schott wrote:On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:sure, i will not use such IDE, 'cause it's fubared. yet it has nothing=20 with "great grammars": it's fubared 'cause the authors were thinking=20 about "how we can write that cool IDE so everybody will prise us" instead=20 of "how we can write our IDE that it will be fast and easy". and generally speaking, IDEs sux.On Wed, 28 Jan 2015 18:54:27 +0000, Zach the Mystic wrote:=20 I take it you also don't care if your IDE lags for 5 seconds every time you type a character?I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive.yep. that is "slave to the machine" approach. i don't really care how hard machine should work to understand what i want. ;-)that's good. as we already have at least 4 codebases to build tools upon,=20 and you gave up using that and insisting on writing another one, and=20 failed... i doubt that your tool was really important or even usable. so=20 now i don't have to try another tool just to throw it away.i.e. i can't see why i have to deal with problems of compiler/tool/editor author. it's easy -- at least in this case -- for human to see where keywords are keywords. machine can see that too with some analysis.=20 I'm a tool writer. If I have enough problems, I don't build the tool. The problem is now your problem.You know what else is easy for humans? Image and audio processing and knowing how to walk. Things that are easy for machines are hard for humans. Things that are easy for humans are hard for machines.i wonder why we don't do all our programs in machine code today. 'cause,=20 you know, it's hard for machine to parse all that languages. so let's use=20 machine code!i did. i'm not using "vanilla" D, that was mentioned in this thread. and=20 you know what? i didn't encounter *any* problems with it.=yet somehow situation is horribly reversed: instead of machine helping me to do what i want, that's me who must obey the machine orders and do the work that machine can do for me.=20 If it really is work that the machine can do for you, why haven't you made the machine do it?
Jan 28 2015
On Thursday, 29 January 2015 at 00:14:51 UTC, ketmar wrote:that's good. as we already have at least 4 codebases to build tools upon, and you gave up using that and insisting on writing another one, and failed... i doubt that your tool was really important or even usable. so now i don't have to try another tool just to throw it away.That's exactly right. I gave up on using dscanner and insisted on writing dscanner instead.
Jan 28 2015
On Thu, 29 Jan 2015 00:29:26 +0000, Brian Schott wrote:On Thursday, 29 January 2015 at 00:14:51 UTC, ketmar wrote:sorry, it wasn't obvious that i was talking not about you in personal, as=20 i read your text as a text about "jack the random, tool writer".=that's good. as we already have at least 4 codebases to build tools upon, and you gave up using that and insisting on writing another one, and failed... i doubt that your tool was really important or even usable. so now i don't have to try another tool just to throw it away.=20 That's exactly right. I gave up on using dscanner and insisted on writing dscanner instead.
Jan 28 2015
On 1/28/15 4:29 PM, Brian Schott wrote:I gave up on using dscanner and insisted on writing dscanner instead.Nice. Interrogative - time to promote dscanner to tools/? Brian, what do you think? -- Andrei
Jan 28 2015
On Thursday, 29 January 2015 at 02:23:56 UTC, Andrei Alexandrescu wrote:Nice. Interrogative - time to promote dscanner to tools/? Brian, what do you think? -- AndreiThat discussion probably deserves its own thread.
Jan 28 2015
On Thursday, 29 January 2015 at 00:14:51 UTC, ketmar wrote:On Thu, 29 Jan 2015 00:03:51 +0000, Brian Schott wrote:why bother when vim exists : )On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:sure, i will not use such IDE, 'cause it's fubared. yet it has nothing with "great grammars": it's fubared 'cause the authors were thinking about "how we can write that cool IDE so everybody will prise us" instead of "how we can write our IDE that it will be fast and easy".On Wed, 28 Jan 2015 18:54:27 +0000, Zach the Mystic wrote:I take it you also don't care if your IDE lags for 5 seconds every time you type a character?I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive.yep. that is "slave to the machine" approach. i don't really care how hard machine should work to understand what i want. ;-)Uncalled for IMO, Schott's tools are great.that's good. as we already have at least 4 codebases to build tools upon, and you gave up using that and insisting on writing another one, and failed... i doubt that your tool was really important or even usable. so now i don't have to try another tool just to throw it away.i.e. i can't see why i have to deal with problems of compiler/tool/editor author. it's easy -- at least in this case -- for human to see where keywords are keywords. machine can see that too with some analysis.I'm a tool writer. If I have enough problems, I don't build the tool. The problem is now your problem.
Jan 28 2015
On Thu, 29 Jan 2015 00:33:39 +0000, weaselcat wrote:Uncalled for IMO, Schott's tools are great.sure. i wasn't talking about Brian in my text, that was my dumbiness that=20 paints the text personal.=
Jan 28 2015
On Thursday, 29 January 2015 at 00:03:52 UTC, Brian Schott wrote:I take it you also don't care if your IDE lags for 5 seconds every time you type a character?Actually, modern parsers can parse ambiguous grammars in O(N) using memoing. Just because you are reluctant to implement a modern parser does not mean that it cannot be done and wrapped up as a library.I'm a tool writer. If I have enough problems, I don't build the tool. The problem is now your problem.D does not even have a published grammar that rejects programs that are not well formed. The problem is not that having a programmer friendly will cause tool writer problems. The problem is in D specification and semantics which are C++ish. What people have requested is not C++ish it is well within a CFG.You know what else is easy for humans? Image and audio processing and knowing how to walk. Things that are easy for machines are hard for humans. Things that are easy for humans are hard for machines.What is easy for a standards committee is to check that their and SQL. Not being able to repesent those in D will make D less attractive. Besides there is no ambiguity in allowing arbitrary field names since they are preceded by a ".". (nobody cares about local variables)
Jan 29 2015
On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis wrote:On Wednesday, January 28, 2015 15:16:50 via Digitalmars-d wrote: We could also remove from all of the attributes, and then that would be "completely consistent," because then only UDAs will have on them. But the next time that we need to add a new attribute (which will hopefully be rare, but it happens sometimes - e.g. with nogc recently), then we'd have to add a new keyword to avoid making things inconsistent, which would likely break existing code. So, more likely, we'd just tack onto it (which can still break code, but only UDA-specific code, so the breakage would be far more minimal), and we'd be right back where we are now.I would love this, and I would be fine with the breakage costs, speaking for myself. About the problem of add more attributes in the future: well, maybe that solution will put a rubber floor on the number of attributes that can be added, as they are already a big number really.... It would be interesting an implementation of both the solutions, and recompile a bunch of big projects out from the registry with dub, just to finally move the discussion on numbers instead of "likely would break a lot / lot more / not so much breakage / etc" ... I know the reply: help us trying out instead of writing! ;-P ;-P --- Paolo
Jan 28 2015
On Wednesday, 28 January 2015 at 14:41:09 UTC, Dicebot wrote:And with no plans to deprecate old syntax even more inconsistency had been introduced.When the problem arises, then.Same goes for possible introduction of new attributes - if syntax for those and UDA is identical, it can break code same as introducing new keywords.Same for any symbol. Do you have a solution?I don't see any _vision_ behind the change, just moving bits around. It is not well-thought.pure, nothrow and return are relatively obscure attributes, so if they change, it should cause minor commotion. If you want to overhaul everything, you can propose a DIP.
Jan 28 2015
On Wednesday, 28 January 2015 at 15:18:44 UTC, Kagamin wrote:Long time ago I have proposed to actually define built-it attributes as UDA's in public druntime module. That way any possible conflict can be resolved relatively easy with dfix using module system disambugation (or just hard-code druntime symbols to be legal to shadow by user ones, though that sounds too much of a magic and surprise)Same goes for possible introduction of new attributes - if syntax for those and UDA is identical, it can break code same as introducing new keywords.Same for any symbol. Do you have a solution?The one who wants to make a change should propose a DIP. I am personally OK with status quo for the time being - there are more important issues.I don't see any _vision_ behind the change, just moving bits around. It is not well-thought.pure, nothrow and return are relatively obscure attributes, so if they change, it should cause minor commotion. If you want to overhaul everything, you can propose a DIP.
Jan 28 2015
On 1/28/15 7:25 AM, Dicebot wrote:The one who wants to make a change should propose a DIP. I am personally OK with status quo for the time being - there are more important issues.BTW what's the deal with std.meta? -- Andrei
Jan 28 2015
On Wednesday, 28 January 2015 at 15:40:31 UTC, Andrei Alexandrescu wrote:On 1/28/15 7:25 AM, Dicebot wrote:I have replied today in relevant PR with few proposals. That one is important to me so I'll keep babysitting it :)The one who wants to make a change should propose a DIP. I am personally OK with status quo for the time being - there are more important issues.BTW what's the deal with std.meta? -- Andrei
Jan 28 2015
On 1/28/15 7:50 AM, Dicebot wrote:On Wednesday, 28 January 2015 at 15:40:31 UTC, Andrei Alexandrescu wrote:Link: https://github.com/D-Programming-Language/phobos/pull/2687 AndreiOn 1/28/15 7:25 AM, Dicebot wrote:I have replied today in relevant PR with few proposals. That one is important to me so I'll keep babysitting it :)The one who wants to make a change should propose a DIP. I am personally OK with status quo for the time being - there are more important issues.BTW what's the deal with std.meta? -- Andrei
Jan 28 2015
On Wednesday, 28 January 2015 at 15:25:05 UTC, Dicebot wrote:On Wednesday, 28 January 2015 at 15:18:44 UTC, Kagamin wrote:I suppose, when UDA conflicts with builtin attribute, that UDA can be still disambiguated through module system.Long time ago I have proposed to actually define built-it attributes as UDA's in public druntime module. That way any possible conflict can be resolved relatively easy with dfix using module system disambugation (or just hard-code druntime symbols to be legal to shadow by user ones, though that sounds too much of a magic and surprise)Same goes for possible introduction of new attributes - if syntax for those and UDA is identical, it can break code same as introducing new keywords.Same for any symbol. Do you have a solution?
Jan 29 2015
On 2015-01-29 16:29, Kagamin wrote:I suppose, when UDA conflicts with builtin attribute, that UDA can be still disambiguated through module system.We can always add another sign in front of new attributes ;) -- /Jacob Carlborg
Jan 29 2015
On Wednesday, 28 January 2015 at 13:14:16 UTC, bearophile wrote:The word "obvious" is important, because usually there are multiple ways to do something, but only one of them should be obvious in Python :-)Yes... but which one is obvious: [0.1*x for x in range(10)] map(operator.mul,range(10),[0.1]*10) numpy.arange(0.,0.95,0.1) numpy.linspace(0,0.9,num=10) list(itertools.islice(itertools.count(0.0, 0.1), 10)) ...
Jan 28 2015
Ola Fosheim Grøstad:[0.1*x for x in range(10)] map(operator.mul,range(10),[0.1]*10) numpy.arange(0.,0.95,0.1) numpy.linspace(0,0.9,num=10) list(itertools.islice(itertools.count(0.0, 0.1), 10))The first one (the list comp) is Pythonic, and it's obviously the obvious one :-) If you want/need to use numpy, the fourth is good. No problems :-) Bye, bearophile
Jan 28 2015
On Wednesday, 28 January 2015 at 13:58:22 UTC, bearophile wrote:The first one (the list comp) is Pythonic, and it's obviously the obvious one :-) If you want/need to use numpy, the fourth is good. No problems :-)Ok, so we agree, but I think the obvious way if we forget about languages would be to combine range with element wise multiplication, e.g. "range(10) .* 0.1". Good usability often means... stick to common conventions, but be internally consistent. Most language designs fail here by not caring enough for the know-how users bring to the table... :-/
Jan 28 2015
On 28.01.15 14:14, bearophile wrote:Dicebot:Yes but also: Practicality beats purity :)Yes, but it didn't also fix anything, only introduced more ways to do the same thing - without any plans for some consistent model.One of the rules of the Python Zen: There should be one-- and preferably only one --obvious way to do it.
Jan 28 2015
On 1/28/15 4:11 AM, Dicebot wrote:On Tuesday, 27 January 2015 at 10:50:53 UTC, Walter Bright wrote:Change has been reverted. -- AndreiThis change didn't break a single line in the libraries or the test suite.Yes, but it didn't also fix anything, only introduced more ways to do the same thing - without any plans for some consistent model. It is simply moving things around for the sake of marking some bugzilla report as closed - there is no consistent rationale for applying to attributes available. Just the fact that change can't possibly break anything doesn't mean it is can't have negative value. It _may_ have some well-though rationale behind I am failing to spot but that is not presented to users in any way.
Jan 28 2015
On Wednesday, 28 January 2015 at 14:59:48 UTC, Andrei Alexandrescu wrote:Change has been reverted. -- AndreiThank you very much. Just to be perfectly clear : I am not against consolidating attributes or even breaking things. Only thing I want is for such changes to be done _simultaneously_ with some more detailed rationale which can be linked from a changelog and would explain everyone outside of this NG what the change is about. It is quite likely that trying to write such rationale will highlight more internal inconsistencies than any discussion could.
Jan 28 2015
On Wednesday, January 28, 2015 06:59:49 Andrei Alexandrescu via Digitalmars-d wrote:Change has been reverted. -- AndreiYay! - Jonathan M Davis
Jan 28 2015
On 26/01/15 22:29, Dicebot via Digitalmars-d wrote:However my complaint is not about the change itself (though I personally disagree with Don reasoning in that issue, it is a delicate matter) but about the fact that it is again done as a casual PR and our breaking change culture does not seem to change : it is still all or nothing approach. No automatic migration tools, no easily found rationale / explanation, no posts in D.announce - just an ordinary commit. No wonder any of more notable change is considered that scary.I don't have any disagreement with your request for better reporting and public justification of decisions like this, but I don't understand why you consider it a breaking change. It's not backwards-incompatible -- the existing pure and nothrow will still work (which I just verified by building druntime and phobos with a dmd instance built from the controversial commit). BTW what is return meant to achieve? I realize I'm not familiar with this attribute.
Jan 28 2015
On Wednesday, 28 January 2015 at 22:58:02 UTC, Joseph Rushton Wakeling wrote:On 26/01/15 22:29, Dicebot via Digitalmars-d wrote:I haven't said it is a breaking change on its own - but that doesn't mean it is any considerably better migration-wise.However my complaint is not about the change itself (though I personally disagree with Don reasoning in that issue, it is a delicate matter) but about the fact that it is again done as a casual PR and our breaking change culture does not seem to change : it is still all or nothing approach. No automatic migration tools, no easily found rationale / explanation, no posts in D.announce - just an ordinary commit. No wonder any of more notable change is considered that scary.I don't have any disagreement with your request for better reporting and public justification of decisions like this, but I don't understand why you consider it a breaking change. It's not backwards-incompatible -- the existing pure and nothrow will still work (which I just verified by building druntime and phobos with a dmd instance built from the controversial commit).BTW what is return meant to achieve? I realize I'm not familiar with this attribute.http://wiki.dlang.org/DIP25
Jan 28 2015
On 29/01/15 00:06, Dicebot via Digitalmars-d wrote:I haven't said it is a breaking change on its own - but that doesn't mean it is any considerably better migration-wise.Yea, you're right, this isn't about whether the feature is good or not (personally, I find Don's case for it persuasive) -- it's about having a well-signposted procedure for changing the language.Oh, of course. Though it feels a bit weird, the possibility to write, safe ref int identity( return ref int x) { return x; }BTW what is return meant to achieve? I realize I'm not familiar with this attribute.http://wiki.dlang.org/DIP25
Jan 28 2015
On Monday, 26 January 2015 at 20:26:02 UTC, Dicebot wrote:It was sad that calls for more breakage were mostly ignored. But there is one thing now that is even worse - referring to #pleasebreakmycode as an excuse to introduce random changes based on random reddit comment - and completely dismissing everything that was said on topic initially. Resulting in exactly the opposite action that was asked to. Please, revert this PR asap. After that it can possibly be introduced after meeting necessary prerequisites: 1) explanation of problem it fixes 2) design rationale for new model 3) evaluation of ROI 4) tools for simple migration - either as part of dfix or compiler This is absolutely mandatory list for any change of language fundamentals to be considered legitimate.+1, and I doubt the ROI analysis will come positive.
Jan 26 2015
On Monday, 26 January 2015 at 19:51:08 UTC, Walter Bright wrote:Frankly, I think that is a great bikeshedding non-issue that distracts us from what is important. I hope that by doing this PR, we can actually decide that it isn't worth it, i.e. I'd be happy to get consensus and revert it.For my part, a 'dfix' solution is worth it. Anything else, not.
Jan 26 2015
Walter Bright:Previously, it's all been advocacy and "break my code"Breaking the code should be justified by a worth gain. This patch is of negative value. Bye, bearophile
Jan 26 2015
On 26/01/2015 21:20, bearophile wrote:Walter Bright:It doesn't break code.Previously, it's all been advocacy and "break my code"Breaking the code should be justified by a worth gain. This patch is of negative value.
Jan 27 2015
On Monday, 26 January 2015 at 19:51:08 UTC, Walter Bright wrote:On 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:Yes, please! (at least about the "break my code" part)Personally, I'd much prefer that we not make this change.It's good to have this discussion. Previously, it's all been advocacy and "break my code" by forcing a change from pure => pure.Just a few days ago on slashdot, an anonymous D user wrote: "A horrible mix of keywords and annotation syntax for function/method attributes ('const', 'pure', and 'nothrow' are all keywords, but ' property', and ' nogc' are annotations)" for why he won't use D anymore.Not a deal-breaker for me, but I agree with the sentiment, and I think it makes for a more professional language if such inconsistencies are addressed.Frankly, I think that is a great bikeshedding non-issue that distracts us from what is important.Yes, there is no correlation between what's important, and what people choose to work on, because there is no consensus on what's important, and if there is it's usually beyond the ability of most contributors, so it doesn't get worked on anyway. Personally, I find small changes like this welcome because they make for a more polished experience.I hope that by doing this PR, we can actually decide that it isn't worth it, i.e. I'd be happy to get consensus and revert it.A dangerous precedent. I suspect the push-back against this change has probably ruined any chance of further polishing the language. From: https://issues.dlang.org/show_bug.cgi?id=13388#c27 ***NO!!!! This attitude is the biggest problem D has. Please, watch Scott Meyer's talk again. "Most D code is yet to be written". The future benefits of fixing this kind of crap, are huge. *** In fact, it is the attitude against change that has put me on the fence about D, when I was quite an advocate about a year ago. It has also made me reluctant to put forth the necessary effort to study and make any significant contributions because the controversy, as exhibited here, would likely erase my entire investment. Instead, I have begun exploring other options while keeping one foot on the raft. I agree that, in general, D should take a more disciplined approach to development, but keep in mind that if contributors have to go through too much controversy and bureaucracy we're not going to see much change (perhaps that's what some want). I feel for Walter. He's damned if he does and damned if he doesn't. Somehow, this herd of cats need to figure out where it wants to go, and I need to figure out whether to go all in or jump ship. MikeI really think that we've passed the point where it's worth fixing it.
Jan 26 2015
On Tuesday, 27 January 2015 at 01:32:23 UTC, Mike wrote:On Monday, 26 January 2015 at 19:51:08 UTC, Walter Bright wrote:+1 to all of this as it mirrors exactly how I feel about D at this point in time. I get the impression it will never be finished because too many are afraid of important breaking changes that seem necessary to get through the last 5%-10% of D2. Cheers, uriOn 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:Yes, please! (at least about the "break my code" part)Personally, I'd much prefer that we not make this change.It's good to have this discussion. Previously, it's all been advocacy and "break my code" by forcing a change from pure => pure.Just a few days ago on slashdot, an anonymous D user wrote: "A horrible mix of keywords and annotation syntax for function/method attributes ('const', 'pure', and 'nothrow' are all keywords, but ' property', and ' nogc' are annotations)" for why he won't use D anymore.Not a deal-breaker for me, but I agree with the sentiment, and I think it makes for a more professional language if such inconsistencies are addressed.Frankly, I think that is a great bikeshedding non-issue that distracts us from what is important.Yes, there is no correlation between what's important, and what people choose to work on, because there is no consensus on what's important, and if there is it's usually beyond the ability of most contributors, so it doesn't get worked on anyway. Personally, I find small changes like this welcome because they make for a more polished experience.I hope that by doing this PR, we can actually decide that it isn't worth it, i.e. I'd be happy to get consensus and revert it.A dangerous precedent. I suspect the push-back against this change has probably ruined any chance of further polishing the language. From: https://issues.dlang.org/show_bug.cgi?id=13388#c27 ***NO!!!! This attitude is the biggest problem D has. Please, watch Scott Meyer's talk again. "Most D code is yet to be written". The future benefits of fixing this kind of crap, are huge. *** In fact, it is the attitude against change that has put me on the fence about D, when I was quite an advocate about a year ago. It has also made me reluctant to put forth the necessary effort to study and make any significant contributions because the controversy, as exhibited here, would likely erase my entire investment. Instead, I have begun exploring other options while keeping one foot on the raft. I agree that, in general, D should take a more disciplined approach to development, but keep in mind that if contributors have to go through too much controversy and bureaucracy we're not going to see much change (perhaps that's what some want). I feel for Walter. He's damned if he does and damned if he doesn't. Somehow, this herd of cats need to figure out where it wants to go, and I need to figure out whether to go all in or jump ship. MikeI really think that we've passed the point where it's worth fixing it.
Jan 26 2015
On 1/26/2015 5:45 PM, uri wrote:I get the impression it will never be finished because too many are afraid of important breaking changes that seem necessary to get through the last 5%-10% of D2.Half want breaking changes, the other half wants stability.
Jan 26 2015
On Tuesday, 27 January 2015 at 01:49:41 UTC, Walter Bright wrote:On 1/26/2015 5:45 PM, uri wrote:I don't know if 'dfix' will be everything I hope it would be, but I would place my bets on it (not that I have much to bet). I think Go has shown decisive leadership on this aspect of language design and maintenance, and I haven't yet heard any negative reports about 'gofix'. If 'dfix' can't work, for some reason I haven't thought of, then somebody just needs to write a big article justifying D's peculiarities, explaining all the tradeoffs, and why the final decisions were made. Then all newcomers can be referred to those articles. But I suspect the reason these issues keep coming up is that they're still alive. I see 'dfix' as a potential win-win, opening up huge possibilities for issues previously thought out-of-the-question. What's keeping you from committing to 'dfix' as the way to solve issues like the one in this thread?I get the impression it will never be finished because too many are afraid of important breaking changes that seem necessary to get through the last 5%-10% of D2.Half want breaking changes, the other half wants stability.
Jan 26 2015
On 1/26/2015 6:15 PM, Zach the Mystic wrote:What's keeping you from committing to 'dfix' as the way to solve issues like the one in this thread?Inertia of people being reluctant to use it. It's still work for people to use, it's not part of their build process.
Jan 26 2015
On Tuesday, 27 January 2015 at 02:40:16 UTC, Walter Bright wrote:On 1/26/2015 6:15 PM, Zach the Mystic wrote:What about compiler integration? I'm talking about fundamental language changes. Why would people use it if it didn't have official backing and wasn't part of the compiler package? In this post: http://forum.dlang.org/post/uimpnhiweuitnnbeqshu forum.dlang.org ... I said: 'For example, let's say dfix is included with the compiler package. Now you get an error, saying: "Error: ` nogc` is no longer accepted, but can be automatically replaced with `nogc`. Run dfix on this file? (y/n)"... or whatever is deemed the secure approach to this feature.' That's what I mean by "commiting to dfix."What's keeping you from committing to 'dfix' as the way to solve issues like the one in this thread?Inertia of people being reluctant to use it. It's still work for people to use, it's not part of their build process.
Jan 26 2015
On Tuesday, 27 January 2015 at 03:25:59 UTC, Zach the Mystic wrote:On Tuesday, 27 January 2015 at 02:40:16 UTC, Walter Bright wrote:This has come up before. I believe if was at DConf 2014 that Walter answered this question. If I remember, the gist was that Walter didn't like the idea that the compiler could rewrite a user's code, he seemed kinda "creeped" out to think that a compiler would do this. Then someone suggested the compiler could generate some type of awk expression that the programmer could run to modify the code. Anyway, just relaying what I remember. IMO, if the rewrite tool was done well it could be a benefit. I think a preview of the changes would be a great feature. But I also understand Walter's point.On 1/26/2015 6:15 PM, Zach the Mystic wrote:What about compiler integration? I'm talking about fundamental language changes. Why would people use it if it didn't have official backing and wasn't part of the compiler package? In this post: http://forum.dlang.org/post/uimpnhiweuitnnbeqshu forum.dlang.org ... I said: 'For example, let's say dfix is included with the compiler package. Now you get an error, saying: "Error: ` nogc` is no longer accepted, but can be automatically replaced with `nogc`. Run dfix on this file? (y/n)"... or whatever is deemed the secure approach to this feature.' That's what I mean by "commiting to dfix."What's keeping you from committing to 'dfix' as the way to solve issues like the one in this thread?Inertia of people being reluctant to use it. It's still work for people to use, it's not part of their build process.
Jan 26 2015
On Tuesday, 27 January 2015 at 03:33:15 UTC, Jonathan Marler wrote:This has come up before. I believe if was at DConf 2014 that Walter answered this question. If I remember, the gist was that Walter didn't like the idea that the compiler could rewrite a user's code, he seemed kinda "creeped" out to think that a compiler would do this. Then someone suggested the compiler could generate some type of awk expression that the programmer could run to modify the code. Anyway, just relaying what I remember.It's only creepy if it doesn't work. And the compiler doesn't need to change the code itself - it merely needs to tell you exactly what to do to fix it. I've thought about this some more. The way I would do it is have the compiler store all files which need to be fixed. Output the list in another file of a different type. Have dfix be able to read that file and automatically fix all files listed. Or just generate a D script to do just that (no need for a whole different file format. Literally just output "dfix.d", which has all the filenames built right into the script, and tell the user to 'dmd -run dfix.d'. Now you have a very clear intermediate step between compilation and user-activated step.
Jan 26 2015
On Tuesday, 27 January 2015 at 03:54:09 UTC, Zach the Mystic wrote:On Tuesday, 27 January 2015 at 03:33:15 UTC, Jonathan Marler wrote:Not a bad idea. Maybe this will be less "creepy" to others :) +1 (what do others think?)This has come up before. I believe if was at DConf 2014 that Walter answered this question. If I remember, the gist was that Walter didn't like the idea that the compiler could rewrite a user's code, he seemed kinda "creeped" out to think that a compiler would do this. Then someone suggested the compiler could generate some type of awk expression that the programmer could run to modify the code. Anyway, just relaying what I remember.It's only creepy if it doesn't work. And the compiler doesn't need to change the code itself - it merely needs to tell you exactly what to do to fix it. I've thought about this some more. The way I would do it is have the compiler store all files which need to be fixed. Output the list in another file of a different type. Have dfix be able to read that file and automatically fix all files listed. Or just generate a D script to do just that (no need for a whole different file format. Literally just output "dfix.d", which has all the filenames built right into the script, and tell the user to 'dmd -run dfix.d'. Now you have a very clear intermediate step between compilation and user-activated step.
Jan 26 2015
On 2015-01-27 04:54, Zach the Mystic wrote:It's only creepy if it doesn't work. And the compiler doesn't need to change the code itself - it merely needs to tell you exactly what to do to fix it. I've thought about this some more. The way I would do it is have the compiler store all files which need to be fixed. Output the list in another file of a different type. Have dfix be able to read that file and automatically fix all files listed. Or just generate a D script to do just that (no need for a whole different file format. Literally just output "dfix.d", which has all the filenames built right into the script, and tell the user to 'dmd -run dfix.d'. Now you have a very clear intermediate step between compilation and user-activated step.Seems overly complicated. How about the compiler just outputs new files instead. -- /Jacob Carlborg
Jan 27 2015
On Tuesday, 27 January 2015 at 10:37:37 UTC, Jacob Carlborg wrote:Seems overly complicated. How about the compiler just outputs new files instead.The thing I care about is that the compiler leaves the user with no doubt as to what he should do next and how to automatically fix his programs. The actual method of doing this is trivial by comparison.
Jan 27 2015
On 1/26/15 7:25 PM, Zach the Mystic wrote:On Tuesday, 27 January 2015 at 02:40:16 UTC, Walter Bright wrote:I'm ready to commit to dfix. Problem is many of the changes suggested are unlikely to mark much improvement, while miring us in the perpetual illusion of making progress. The fact that we can avail ourselves of a tactical tool that makes changes easy is helpful but also opens opportunity of abuse. Let's stop shuffling the deck. I mean it. Stop shuffling the freaking deck. Fix the real issues in the language. Add new libraries. Be original. Be creative. Do real work. Thanks, AndreiOn 1/26/2015 6:15 PM, Zach the Mystic wrote:What about compiler integration? I'm talking about fundamental language changes. Why would people use it if it didn't have official backing and wasn't part of the compiler package? In this post: http://forum.dlang.org/post/uimpnhiweuitnnbeqshu forum.dlang.org ... I said: 'For example, let's say dfix is included with the compiler package. Now you get an error, saying: "Error: ` nogc` is no longer accepted, but can be automatically replaced with `nogc`. Run dfix on this file? (y/n)"... or whatever is deemed the secure approach to this feature.' That's what I mean by "commiting to dfix."What's keeping you from committing to 'dfix' as the way to solve issues like the one in this thread?Inertia of people being reluctant to use it. It's still work for people to use, it's not part of their build process.
Jan 26 2015
On Tuesday, 27 January 2015 at 04:10:24 UTC, Andrei Alexandrescu wrote:On 1/26/15 7:25 PM, Zach the Mystic wrote:Well said. I've been wavering for a few months between D and Python for teams on smaller internal projects. IMO this is the right attitude from core D devs to finish off D2. Cheers, uriOn Tuesday, 27 January 2015 at 02:40:16 UTC, Walter Bright wrote:I'm ready to commit to dfix. Problem is many of the changes suggested are unlikely to mark much improvement, while miring us in the perpetual illusion of making progress. The fact that we can avail ourselves of a tactical tool that makes changes easy is helpful but also opens opportunity of abuse. Let's stop shuffling the deck. I mean it. Stop shuffling the freaking deck. Fix the real issues in the language. Add new libraries. Be original. Be creative. Do real work. Thanks, AndreiOn 1/26/2015 6:15 PM, Zach the Mystic wrote:What about compiler integration? I'm talking about fundamental language changes. Why would people use it if it didn't have official backing and wasn't part of the compiler package? In this post: http://forum.dlang.org/post/uimpnhiweuitnnbeqshu forum.dlang.org ... I said: 'For example, let's say dfix is included with the compiler package. Now you get an error, saying: "Error: ` nogc` is no longer accepted, but can be automatically replaced with `nogc`. Run dfix on this file? (y/n)"... or whatever is deemed the secure approach to this feature.' That's what I mean by "commiting to dfix."What's keeping you from committing to 'dfix' as the way to solve issues like the one in this thread?Inertia of people being reluctant to use it. It's still work for people to use, it's not part of their build process.
Jan 26 2015
On Tuesday, 27 January 2015 at 04:10:24 UTC, Andrei Alexandrescu wrote:I'm ready to commit to dfix. Problem is many of the changes suggested are unlikely to mark much improvement, while miring us in the perpetual illusion of making progress.I don't think there's any illusion about D's great progress. D really has been making incredible progress. But also, don't you think it's progress to really solve issues, even little ones, such that threads like this never take place again? The way I see it, it's either dfix or the status quo for this issue. The current pull request is not decisive enough. So I talk about dfix, because it seems like the right tool for the job. Yes, it's tantalizing to imagine what other uses it has, but we won't know until it's in the tool belt and available to use. Maybe it'll have no other uses. Maybe all other potential uses will be "illusions of progress". But to me, it's attractive. It offers the best odds at really closing the case on a lot of nitpicks people have about D right now.The fact that we can avail ourselves of a tactical tool that makes changes easy is helpful but also opens opportunity of abuse.What I hear you say is that you may not want the added responsibility of yours and Walter's making decisions on all the new possibilities it opens up. And maybe you're right about that. All I can do is make arguments, while you two have to decide Yes, or No. I want my arguments to help make your decisions easier. That's my goal. But I won't deny that (to use a tired cliche that actually makes sense here) with added power comes added responsibility.Let's stop shuffling the deck. I mean it. Stop shuffling the freaking deck. Fix the real issues in the language. Add new libraries. Be original. Be creative. Do real work.How is the pull request which started this post not shuffling the deck? If it's not an issue, why make a pull request to begin with? Also, I hope it helps to realize that not everyone is qualified to give valuable feedback on some of the larger issues D faces. I definitely feel out of my league on many topics here, notwithstanding the crazy ideas that just pop into my head sometimes. :-/ But simply allowing people to chatter about the issues they do feel competent to discuss can have a very positive effect on the community. I don't think it stops you or anyone else from starting threads on the bigger animals in the arena. Not everyone's playing with the same set of marbles here. But I'll admit I don't know exactly how you feel. Just focus on what you care about and be honest about what you currently consider worthy and not worthy of your very valuable time. Destroy! :-)
Jan 26 2015
On 1/26/15 5:45 PM, uri wrote:I get the impression it will never be finished because too many are afraid of important breaking changes that seem necessary to get through the last 5%-10% of D2.Fiddling with " " is not important. -- Andrei
Jan 26 2015
On 1/26/15 5:32 PM, Mike wrote:The future benefits of fixing this kind of crap, are huge.IMHO this is myopic. We have much larger issues with e.g. safety, shared, and the core threading library, than syntactic minutia. All of this changing what works has its value, but that pales in comparison. Yes, a light bulb can be bright, but it pales when set against the sun. Context, perspective, vision - that's what matters now. -- Andrei
Jan 26 2015
On 1/26/2015 7:58 PM, Andrei Alexandrescu wrote:On 1/26/15 5:32 PM, Mike wrote:I agree. Let's not get mired in an "illusion of progress".The future benefits of fixing this kind of crap, are huge.IMHO this is myopic. We have much larger issues with e.g. safety, shared, and the core threading library, than syntactic minutia. All of this changing what works has its value, but that pales in comparison. Yes, a light bulb can be bright, but it pales when set against the sun. Context, perspective, vision - that's what matters now. -- Andrei
Jan 26 2015
On Tuesday, 27 January 2015 at 03:58:34 UTC, Andrei Alexandrescu wrote:On 1/26/15 5:32 PM, Mike wrote:Agreed, but... It is not the case that trivial matters like this are taking resources away from somewhere else. Take away all the trivia, and the important stuff still wouldn't get done because each cat in this herd disagrees on where to go or how to get there. IMO, none of these light bulbs are blocking the sun, and at least they are making some contribution to the ambient light. MikeThe future benefits of fixing this kind of crap, are huge.IMHO this is myopic. We have much larger issues with e.g. safety, shared, and the core threading library, than syntactic minutia. All of this changing what works has its value, but that pales in comparison.
Jan 26 2015
On 1/26/15 10:32 PM, Mike wrote:On Tuesday, 27 January 2015 at 03:58:34 UTC, Andrei Alexandrescu wrote:I think they are. No reply needed. AndreiOn 1/26/15 5:32 PM, Mike wrote:Agreed, but... It is not the case that trivial matters like this are taking resources away from somewhere else.The future benefits of fixing this kind of crap, are huge.IMHO this is myopic. We have much larger issues with e.g. safety, shared, and the core threading library, than syntactic minutia. All of this changing what works has its value, but that pales in comparison.
Jan 26 2015
On Tue, 27 Jan 2015 01:32:21 +0000, Mike wrote:In fact, it is the attitude against change that has put me on the fence about D, when I was quite an advocate about a year ago. It has also made me reluctant to put forth the necessary effort to study and make any significant contributions because the controversy, as exhibited here, would likely erase my entire investment. Instead, I have begun exploring other options while keeping one foot on the raft.heh. i was very passionate about D, and i started the process of=20 migration of all our work projects (i'm a head of software company with=20 ~100 employees, if anybody is interested) to D. but then i realised that=20 D -- being a best programming language i've seen in my life -- is a toy=20 project. just think about it as a personal toy. and then you'll know what=20 expect from it.=
Jan 27 2015
On Tuesday, 27 January 2015 at 08:07:11 UTC, ketmar wrote:heh. i was very passionate about D, and i started the process of migration of all our work projects (i'm a head of software company with ~100 employees, if anybody is interested) to D. but then i realised that D -- being a best programming language i've seen in my life -- is a toy project. just think about it as a personal toy. and then you'll know what expect from it.A head of a 1000 employee software company would certainly have the power to change that rather than spending his time complaining on a NG.
Jan 27 2015
On Tuesday, 27 January 2015 at 08:44:19 UTC, deadalnix wrote:On Tuesday, 27 January 2015 at 08:07:11 UTC, ketmar wrote:If I have interpreted this post in the correct way, this is a very unfair comment, deadline. --- Paoloheh. i was very passionate about D, and i started the process of migration of all our work projects (i'm a head of software company with ~100 employees, if anybody is interested) to D. but then i realised that D -- being a best programming language i've seen in my life -- is a toy project. just think about it as a personal toy. and then you'll know what expect from it.A head of a 1000 employee software company would certainly have the power to change that rather than spending his time complaining on a NG.
Jan 27 2015
On Tue, 27 Jan 2015 08:44:17 +0000, deadalnix wrote:On Tuesday, 27 January 2015 at 08:07:11 UTC, ketmar wrote:i don't know where you found that "1000" number, i was talking about=20 "100". it's a very different thing. and then: do you proposing a fork? sure, i can do that. actually, i'm=20 using a very different D already (heh, people that are interested in my=20 public code -- noone, actually -- may notice that all my modules are=20 "aliced" now; that's 'cause i want them to fail early instead of being=20 asked why they errored in the middle). but will it be good for D? i'm not=20 making my fork public for a reason. and i'm writing here for a reason=20 too. did you notice that almost all of my topics (not that many,=20 actually) got a lenghty discussion? isn't that a sign that i'm talking=20 about important things?=heh. i was very passionate about D, and i started the process of migration of all our work projects (i'm a head of software company with ~100 employees, if anybody is interested) to D. but then i realised that D -- being a best programming language i've seen in my life -- is a toy project. just think about it as a personal toy. and then you'll know what expect from it.=20 A head of a 1000 employee software company would certainly have the power to change that rather than spending his time complaining on a NG.
Jan 27 2015
On Tuesday, 27 January 2015 at 08:07:11 UTC, ketmar wrote:On Tue, 27 Jan 2015 01:32:21 +0000, Mike wrote: i started the process of migration of all our work projects (i'm a head of software company with ~100 employees, if anybody is interested) to D. but then i realised that D -- being a best programming language i've seen in my life -- is a toy project. just think about it as a personal toy. and then you'll know what expect from it.I'm interested! I'm interested! ;-P Our jobs are similar: we have to scout out new technologies for our companies, and, with an hand on the hearth and fingers crossed, we have to judge the risks/benefits about spending money and time on them. It's not an easy job in my opinion, expecially nowadays with all that trees in the forest... I strongly believe in D, and we have migrated all our major projects over it, but sometimes, when I'm alone with my thoughts, I not sure if the "force is strong in me" like at the beginning... Well, we'll see: alea iacta est. --- Paolo
Jan 27 2015
On Tue, 27 Jan 2015 08:47:43 +0000, Paolo Invernizzi wrote:On Tuesday, 27 January 2015 at 08:07:11 UTC, ketmar wrote:i believe in D too, and i want it to succeed -- not only for me. that's=20 why i'm writing here. i'm not attacking it for the sake of attack, and i=20 deliberately took the position of outcast.=On Tue, 27 Jan 2015 01:32:21 +0000, Mike wrote: i started the process of migration of all our work projects (i'm a head of software company with ~100 employees, if anybody is interested) to D. but then i realised that D -- being a best programming language i've seen in my life -- is a toy project. just think about it as a personal toy. and then you'll know what expect from it.=20 I'm interested! I'm interested! ;-P =20 Our jobs are similar: we have to scout out new technologies for our companies, and, with an hand on the hearth and fingers crossed, we have to judge the risks/benefits about spending money and time on them. =20 It's not an easy job in my opinion, expecially nowadays with all that trees in the forest... =20 I strongly believe in D, and we have migrated all our major projects over it, but sometimes, when I'm alone with my thoughts, I not sure if the "force is strong in me" like at the beginning... =20 Well, we'll see: alea iacta est.
Jan 27 2015
On Tuesday, 27 January 2015 at 09:20:51 UTC, ketmar wrote:i believe in D too, and i want it to succeed -- not only for me. that's why i'm writing here. i'm not attacking it for the sake of attack, and i deliberately took the position of outcast.Strategically, what has your outcast position gotten you? What incentive do you have to keep on with that choice?
Jan 27 2015
On Tue, 27 Jan 2015 16:22:17 +0000, Zach the Mystic wrote:On Tuesday, 27 January 2015 at 09:20:51 UTC, ketmar wrote:i have an answer, but sorry, i prefer to not make it public.=i believe in D too, and i want it to succeed -- not only for me. that's why i'm writing here. i'm not attacking it for the sake of attack, and i deliberately took the position of outcast.=20 Strategically, what has your outcast position gotten you? What incentive do you have to keep on with that choice?
Jan 27 2015
On 2015-01-26 20:50, Walter Bright wrote:It's good to have this discussion. Previously, it's all been advocacy and "break my code" by forcing a change from pure => pure. Just a few days ago on slashdot, an anonymous D user wrote: "A horrible mix of keywords and annotation syntax for function/method attributes ('const', 'pure', and 'nothrow' are all keywords, but ' property', and ' nogc' are annotations)" for why he won't use D anymore. Frankly, I think that is a great bikeshedding non-issue that distracts us from what is important. I hope that by doing this PR, we can actually decide that it isn't worth it, i.e. I'd be happy to get consensus and revert it.How is this change going to help when there's still a bunch of attributes that can not be prefixed with ' ', immutable, const, public and so on? -- /Jacob Carlborg
Jan 27 2015
On Tue, 27 Jan 2015 11:20:41 +0100, Jacob Carlborg wrote:On 2015-01-26 20:50, Walter Bright wrote: =20who cares? it's SLASHDOT USER! i doubt that he wrote anything except=20 "helloworld" in D, but it's SLASHDOT USER! reddit and slashdot users are=20 first-class citizens for D, and actual D users are of no importance.=It's good to have this discussion. Previously, it's all been advocacy and "break my code" by forcing a change from pure =3D> pure. Just a few days ago on slashdot, an anonymous D user wrote: "A horrible mix of keywords and annotation syntax for function/method attributes ('const', 'pure', and 'nothrow' are all keywords, but ' property', and ' nogc' are annotations)" for why he won't use D anymore. Frankly, I think that is a great bikeshedding non-issue that distracts us from what is important. I hope that by doing this PR, we can actually decide that it isn't worth it, i.e. I'd be happy to get consensus and revert it.=20 How is this change going to help when there's still a bunch of attributes that can not be prefixed with ' ', immutable, const, public and so on?
Jan 27 2015
On 27/01/2015 10:20, Jacob Carlborg wrote:How is this change going to help when there's still a bunch of attributes that can not be prefixed with ' ', immutable, const, public and so on?Those can apply to variables too. We could use built-in attributes for functions only (https://issues.dlang.org/show_bug.cgi?id=13388#c31).
Jan 27 2015
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote:if we deprecate pure and nothrow without , then we'll be forced to change pretty much every D program in existence.A trivial search and replace. Some might be against this change now, but 5 years from we'll profit from it. Mike
Jan 26 2015
On 1/26/2015 2:57 PM, Mike wrote:On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote:It's the continuous drip-drip-drip of this that ticks people off.if we deprecate pure and nothrow without , then we'll be forced to change pretty much every D program in existence.A trivial search and replace. Some might be against this change now, but 5 years from we'll profit from it.
Jan 26 2015
On 1/26/2015 1:50 AM, Brian Schott wrote:I'm running out of ideas for DConf topics.I don't think there's any risk of bugzilla going down to zero by May :-)
Jan 26 2015
On Mon, 26 Jan 2015 09:29:40 +0000, Paolo Invernizzi wrote: i'm scared. does that mean that my rants about "consistency" was sane=20 after all? and now i have to find something else to attack? (sigh) poor=20 me.=
Jan 26 2015
On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote:If someone is not following the merges, well... [1] !! --- Paolo [1] http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171 hookshot-fe4-cp1-prd.iad.github.net.mailIn case anybody was wondering, dfix has had the ability to do the "nothrow" -> " nothrow" conversion since October.
Jan 26 2015