www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Rather D1 then D2

reply new <new new.com> writes:
hi,
is it possible to get a bug fixed x64 compiling D1?
I don't want to start some rant, but i don't like D2. D1 is 
compact and not so overloaded with funny attributes.

thanks
Sep 21 2018
next sibling parent reply 0xEAB <desisma heidel.beer> writes:
On Friday, 21 September 2018 at 20:33:01 UTC, new wrote:

 D1 is compact and not so overloaded with funny attributes.


just don't use all those funky attributes and you're fine :)
Sep 21 2018
parent new <new new.com> writes:
On Friday, 21 September 2018 at 20:44:12 UTC, 0xEAB wrote:

 On Friday, 21 September 2018 at 20:33:01 UTC, new wrote:

 D1 is compact and not so overloaded with funny attributes.


 just don't use all those funky attributes and you're fine :)


bs - be serious.
i don't wand to use D2, but D1.
Sep 21 2018
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, September 21, 2018 2:33:01 PM MDT new via Digitalmars-d wrote:

 hi,
 is it possible to get a bug fixed x64 compiling D1?
 I don't want to start some rant, but i don't like D2. D1 is
 compact and not so overloaded with funny attributes.


Official support of D1 was dropped nearly 6 years ago:

https://forum.dlang.org/post/
afjlgjcftngzannrhtuf dfeed.kimsufi.thecybershadow.net

So, there will be no more official fixes or releases for D1. If you can find
someone willing to fix a D1 bug for you (or fix it yourself) in your own
fork, then it can certainly be fixed, but that's pretty much the only way
it's going to be fixed.

The sad truth is that if you really do want to continue to use D1, you're
going to have to maintain it yourself or find a group of people willing to
do so; otherwise eventually, the language and its libraries are going to
become unusable due to a lack of maintenance. So, I fully expect that at
some point here, you're going to have to switch to a different language.
Whether that's D2 is up to you, but D1 is not maintained and is not going to
be.

- Jonathan M Davis
Sep 21 2018
next sibling parent reply new <new new.com> writes:
On Friday, 21 September 2018 at 21:07:57 UTC, Jonathan M Davis 
wrote:

 On Friday, September 21, 2018 2:33:01 PM MDT new via 
 Digitalmars-d wrote:

 [...]


 Official support of D1 was dropped nearly 6 years ago:

 [...]


Thank you for your answer. too bad - have to think about it.
Sep 21 2018
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Friday, 21 September 2018 at 21:17:52 UTC, new wrote:

 Thank you for your answer. too bad - have to think about it.


You might be interested in the Volt language, which follows in 
D1's footsteps:

https://github.com/VoltLang/Volta

I believe it was created by some D users with the same opinion on 
D1/D2. Syntax is also very much like D1.
Sep 21 2018
parent new <new new.com> writes:
On Saturday, 22 September 2018 at 04:45:47 UTC, Vladimir 
Panteleev wrote:

 On Friday, 21 September 2018 at 21:17:52 UTC, new wrote:

 Thank you for your answer. too bad - have to think about it.


 You might be interested in the Volt language, which follows in 
 D1's footsteps:

 https://github.com/VoltLang/Volta

 I believe it was created by some D users with the same opinion 
 on D1/D2. Syntax is also very much like D1.


thank you for the pointer, i definitely will look at this closer.
Sep 22 2018
prev sibling parent reply Nemanja =?UTF-8?B?Qm9yacSH?= <dlang nemanjaboric.com> writes:
On Friday, 21 September 2018 at 21:07:57 UTC, Jonathan M Davis 
wrote:

 The sad truth is that if you really do want to continue to use 
 D1, you're going to have to maintain it yourself or find a 
 group of people willing to do so;


Sociomantic "maintains" (well, much more in the past than today) 
D1 compiler and you can find latest releases here (Ubuntu): 
https://bintray.com/sociomantic-tsunami/dlang/dmd1 (direct link 
https://bintray.com/sociomantic-tsunami/dlang/dmd1/v1.082.1#files) or you can
compile https://github.com/dlang/dmd/tree/dmd-1.x yourself and hope that the
compiler bug is fixed - we've certainly fixed a lot of them in the past years
(decade?).

But - Sociomantic doesn't officially maintain D1 language (we're 
in process of moving our entire codebase to D2 - which is a long 
process, but we're getting there - checkout some of dconf videos 
where it was talked about it) - it is just about fixing bugs 
where ROI is good enough to justify fixing (which is in many 
cases - just backporting D2 compiler fixes, which is also not 
trivial), so don't expect any commitment, rather - expect this 
commitment to stop.

That being said - I want to point out something that was already 
mentioned here - it is possible to use D2 subsets that are "D1 
minded" (for example, Sociomantic is not the best codebase to 
look for modern D code), and our all D1 projects now compile as 
D2 code after simple machine translation (take a look into 
https://github.com/sociomantic-tsunami/ocean/ and run `make 
d2conv` and check the output - `make DVER=2 ` will compile 
generated D2 code and run unittests - don't forget to init git 
submodules and to install dependencies - 
https://bintray.com/sociomantic-tsunami/dlang/d1to2fix - or just 
run in sociomantictsunami/dlangdevel docker image).

So it is possible to use D2 language and compiler and avoid all 
the features that you don't like, at least to a reasonable 
degree, and as a bonus you still get to cherry pick D2 features 
you like (and there are some even for D1 minded person).
Sep 22 2018
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Saturday, 22 September 2018 at 08:48:37 UTC, Nemanja Borić 
wrote:

 On Friday, 21 September 2018 at 21:07:57 UTC, Jonathan M Davis 
 wrote:

 [...]


 Sociomantic "maintains" (well, much more in the past than 
 today) D1 compiler and you can find latest releases here 
 (Ubuntu): https://bintray.com/sociomantic-tsunami/dlang/dmd1 
 (direct link 
 https://bintray.com/sociomantic-tsunami/dlang/dmd1/v1.082.1#files) or you can
compile https://github.com/dlang/dmd/tree/dmd-1.x yourself and hope that the
compiler bug is fixed - we've certainly fixed a lot of them in the past years
(decade?).

 [...]


I'd be interested to hear/read about the features that some 
developers don't like with D2.  Maybe you can point me to places 
where this has been shared in the past and/or reply with your own 
perspective? Others feel free to chime in as well.  I should make 
it clear this is just a request to gather data, I'm not looking 
to start a debate, just wanting to see what can be learned from 
this. Thanks.
Sep 22 2018
parent reply bauss <jj_1337 live.dk> writes:
On Saturday, 22 September 2018 at 09:42:48 UTC, Jonathan Marler 
wrote:

 I'd be interested to hear/read about the features that some 
 developers don't like with D2.


I'm going to guess it has to do with all the attributes for 
functions which you often have to remember is it  attribute or is 
it just attribute like is it  nogc or is it nogc etc.

It's one of the things that probably throws off a lot of new 
users of D, because they feel like they __have__ to know those 
although they're often optional and you can live without them 
completely.

They make the language seem bloated.
Sep 22 2018
parent reply new <new new.com> writes:
On Saturday, 22 September 2018 at 10:53:25 UTC, bauss wrote:

 On Saturday, 22 September 2018 at 09:42:48 UTC, Jonathan Marler 
 wrote:

 I'd be interested to hear/read about the features that some 
 developers don't like with D2.


 I'm going to guess it has to do with all the attributes for 
 functions which you often have to remember is it  attribute or 
 is it just attribute like is it  nogc or is it nogc etc.

 It's one of the things that probably throws off a lot of new 
 users of D, because they feel like they __have__ to know those 
 although they're often optional and you can live without them 
 completely.

 They make the language seem bloated.


the language is bloated. trying to read the source of D2 makes 
gives you the feeling of getting eye cancer.
so we decided if D at all then it should be D1.
Sep 22 2018
next sibling parent reply new <new new.com> writes:
On Saturday, 22 September 2018 at 13:22:03 UTC, new wrote:

 On Saturday, 22 September 2018 at 10:53:25 UTC, bauss wrote:

 On Saturday, 22 September 2018 at 09:42:48 UTC, Jonathan 
 Marler wrote:

 [...]


 I'm going to guess it has to do with all the attributes for 
 functions which you often have to remember is it  attribute or 
 is it just attribute like is it  nogc or is it nogc etc.

 It's one of the things that probably throws off a lot of new 
 users of D, because they feel like they __have__ to know those 
 although they're often optional and you can live without them 
 completely.

 They make the language seem bloated.


 the language is bloated. trying to read the source of D2 makes 
 gives you the feeling of getting eye cancer.
 so we decided if D at all then it should be D1.


sorry i meant D2-phobos
Sep 22 2018
parent Kagamin <spam here.lot> writes:
On Saturday, 22 September 2018 at 13:24:57 UTC, new wrote:

 the language is bloated. trying to read the source of D2 makes 
 gives you the feeling of getting eye cancer.
 so we decided if D at all then it should be D1.


 sorry i meant D2-phobos


It's only a coding convention for phobos and a consequence of 
overengineering as phobos tries to satisfy all possible needs, 
it's not a property of the language. There's a D2 port of tango 
https://github.com/SiegeLord/Tango-D2 and it has almost no 
attribute creep, only  property, but that one is pretty 
superficial and shouldn't hurt to remove with simple sed 
'/ property //'.
Sep 24 2018
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 23/09/2018 1:22 AM, new wrote:

 On Saturday, 22 September 2018 at 10:53:25 UTC, bauss wrote:

 On Saturday, 22 September 2018 at 09:42:48 UTC, Jonathan Marler wrote:

 I'd be interested to hear/read about the features that some 
 developers don't like with D2.


 I'm going to guess it has to do with all the attributes for functions 
 which you often have to remember is it  attribute or is it just 
 attribute like is it  nogc or is it nogc etc.

 It's one of the things that probably throws off a lot of new users of 
 D, because they feel like they __have__ to know those although they're 
 often optional and you can live without them completely.

 They make the language seem bloated.


 
 the language is bloated. trying to read the source of D2 makes gives you 
 the feeling of getting eye cancer.
 so we decided if D at all then it should be D1.


Then D isn't the right choice for you.
Sep 22 2018
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Saturday, 22 September 2018 at 13:25:27 UTC, rikki cattermole 
wrote:

 Then D isn't the right choice for you.


I think it makes for a better community if we can be more 
welcoming, helpful a gracious instead of responding to criticism 
this way. This is someone who saw enough potential with D to end 
up on the forums but had some gripes with it, after all who 
doesn't? I'm glad he took the initiative to provide us with good 
feedback, and he's not the first to take issue with the 
inconsistent ' ' attribute syntax.  I'm sure everyone can agree 
this inconsistency is less than ideal but that doesn't mean D 
isn't right for them and we should respond this feedback like 
this with thanks rather than dismissal.
Sep 22 2018
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Saturday, 22 September 2018 at 14:31:20 UTC, Jonathan Marler 
wrote:

 On Saturday, 22 September 2018 at 13:25:27 UTC, rikki 
 cattermole wrote:

 Then D isn't the right choice for you.


 I think it makes for a better community if we can be more 
 welcoming, helpful a gracious instead of responding to 
 criticism this way. This is someone who saw enough potential 
 with D to end up on the forums but had some gripes with it, 
 after all who doesn't? I'm glad he took the initiative to 
 provide us with good feedback, and he's not the first to take 
 issue with the inconsistent ' ' attribute syntax.  I'm sure 
 everyone can agree this inconsistency is less than ideal but 
 that doesn't mean D isn't right for them and we should respond 
 this feedback like this with thanks rather than dismissal.


That inconsistency is an issue for me. I wish there a clear 
decision to make things consistent.
Sep 22 2018
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Saturday, 22 September 2018 at 15:25:32 UTC, aberba wrote:

 On Saturday, 22 September 2018 at 14:31:20 UTC, Jonathan Marler 
 wrote:

 On Saturday, 22 September 2018 at 13:25:27 UTC, rikki 
 cattermole wrote:

 Then D isn't the right choice for you.


 I think it makes for a better community if we can be more 
 welcoming, helpful a gracious instead of responding to 
 criticism this way. This is someone who saw enough potential 
 with D to end up on the forums but had some gripes with it, 
 after all who doesn't? I'm glad he took the initiative to 
 provide us with good feedback, and he's not the first to take 
 issue with the inconsistent ' ' attribute syntax.  I'm sure 
 everyone can agree this inconsistency is less than ideal but 
 that doesn't mean D isn't right for them and we should respond 
 this feedback like this with thanks rather than dismissal.


 That inconsistency is an issue for me. I wish there a clear 
 decision to make things consistent.


Yeah there's been alot of discussion around it over the years, 
which is why I put this together about 4 years ago:

https://wiki.dlang.org/Language_Designs_Explained#Function_attributes

Gosh I've forgotten how long I've been using D.
Sep 22 2018
parent reply Henrik <henrik nothing.com> writes:
On Saturday, 22 September 2018 at 15:45:09 UTC, Jonathan Marler 
wrote:

 On Saturday, 22 September 2018 at 15:25:32 UTC, aberba wrote:

 On Saturday, 22 September 2018 at 14:31:20 UTC, Jonathan 
 Marler wrote:

 On Saturday, 22 September 2018 at 13:25:27 UTC, rikki 
 cattermole wrote:

 Then D isn't the right choice for you.


 I think it makes for a better community if we can be more 
 welcoming, helpful a gracious instead of responding to 
 criticism this way. This is someone who saw enough potential 
 with D to end up on the forums but had some gripes with it, 
 after all who doesn't? I'm glad he took the initiative to 
 provide us with good feedback, and he's not the first to take 
 issue with the inconsistent ' ' attribute syntax.  I'm sure 
 everyone can agree this inconsistency is less than ideal but 
 that doesn't mean D isn't right for them and we should 
 respond this feedback like this with thanks rather than 
 dismissal.


 That inconsistency is an issue for me. I wish there a clear 
 decision to make things consistent.


 Yeah there's been alot of discussion around it over the years, 
 which is why I put this together about 4 years ago:

 https://wiki.dlang.org/Language_Designs_Explained#Function_attributes

 Gosh I've forgotten how long I've been using D.


Interesting article.

"int safe = 0; // This code would break if "safe" was added as a 
keyword"

My question here: why didn't D use a similar solution as C when 
dealing with these things? Look at the introduction of the bool 
datatype in C99. They created the compiler reserved type "_Bool" 
and put "typedef _Bool bool" in "stdbool.h". The people wanting 
to use this new feature can include this header, and other can 
leave it be. No ugly " " polluting the language on every line 
where it's used. Wouldn't a similar solution have been possible 
in D?
Sep 22 2018
next sibling parent reply JN <666total wp.pl> writes:
On Saturday, 22 September 2018 at 19:04:41 UTC, Henrik wrote:

 "int safe = 0; // This code would break if "safe" was added as 
 a keyword"


I'm not buying this one. The compiler could issue a warning, 
something like "Warning: keyword safe will become a keyword in 
future version, please rename the identifier", then after few 
months remove it.

Some code will break, sure, but it's a mechanical change that 
should be possible to apply by some tool. Also, with proper dub 
package validation, it should be easy to assess how many packages 
actually break if any. It's one thing to break vibe-d or 
diamondmvc, it's other thing to break helloworld-d that wasn't 
updated in seven years.
Sep 22 2018
parent reply 0xEAB <desisma heidel.beer> writes:
On Saturday, 22 September 2018 at 19:41:16 UTC, JN wrote:

 Some code will break, sure, but it's a mechanical change that 
 should be possible to apply by some tool.


Who will run this tool? Who's gonna merge the PRs created with 
this tool?
Compatibility fixes would have been easy in the past in many 
cases - nevertheless, it needs someone to apply them. Which often 
did not happen in the past, unfortunately.



 Also, with proper dub package validation, it should be easy to 
 assess how many packages actually break if any.


Now that there's the tester by Neia, one will see whether this 
works in practice. Time will tell.
Sep 22 2018
parent Neia Neutuladh <neia ikeran.org> writes:
On Saturday, 22 September 2018 at 20:34:50 UTC, 0xEAB wrote:

 On Saturday, 22 September 2018 at 19:41:16 UTC, JN wrote:

 Some code will break, sure, but it's a mechanical change that 
 should be possible to apply by some tool.


 Who will run this tool? Who's gonna merge the PRs created with 
 this tool?
 Compatibility fixes would have been easy in the past in many 
 cases - nevertheless, it needs someone to apply them. Which 
 often did not happen in the past, unfortunately.


The demon on my shoulder is telling me to add it to dub.

Record the last used compiler in dub.selections.json. Add every 
incompatibility to dfix. If your project was last built with, 
say, 2.079.0, then dub will detect the current compiler and run 
dfix with the necessary upgrades when building the project. And 
it runs `git reset --hard` before doing any of these checks, or 
applies them in your project's .dub directory.

This is pretty cruddy, but it protects you somewhat from 
unmaintained projects.

Though honestly, having a stable compiler version and 
recommending that people stick with it for multiple years would 
also help a lot.
Sep 23 2018
prev sibling next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Saturday, 22 September 2018 at 19:04:41 UTC, Henrik wrote:

 On Saturday, 22 September 2018 at 15:45:09 UTC, Jonathan Marler 
 wrote:

 On Saturday, 22 September 2018 at 15:25:32 UTC, aberba wrote:

 On Saturday, 22 September 2018 at 14:31:20 UTC, Jonathan 
 Marler wrote:

 On Saturday, 22 September 2018 at 13:25:27 UTC, rikki 
 cattermole wrote:

 Then D isn't the right choice for you.


 I think it makes for a better community if we can be more 
 welcoming, helpful a gracious instead of responding to 
 criticism this way. This is someone who saw enough potential 
 with D to end up on the forums but had some gripes with it, 
 after all who doesn't? I'm glad he took the initiative to 
 provide us with good feedback, and he's not the first to 
 take issue with the inconsistent ' ' attribute syntax.  I'm 
 sure everyone can agree this inconsistency is less than 
 ideal but that doesn't mean D isn't right for them and we 
 should respond this feedback like this with thanks rather 
 than dismissal.


 That inconsistency is an issue for me. I wish there a clear 
 decision to make things consistent.


 Yeah there's been alot of discussion around it over the years, 
 which is why I put this together about 4 years ago:

 https://wiki.dlang.org/Language_Designs_Explained#Function_attributes

 Gosh I've forgotten how long I've been using D.


 Interesting article.

 "int safe = 0; // This code would break if "safe" was added as 
 a keyword"

 My question here: why didn't D use a similar solution as C when 
 dealing with these things? Look at the introduction of the bool 
 datatype in C99. They created the compiler reserved type 
 "_Bool" and put "typedef _Bool bool" in "stdbool.h". The people 
 wanting to use this new feature can include this header, and 
 other can leave it be. No ugly " " polluting the language on 
 every line where it's used. Wouldn't a similar solution have 
 been possible in D?


That works for types but wouldn't work for keywords. Keywords 
have special meaning in the lexical stage and you can't 
extend/change the grammar of the language via an alias or 
typedef.  You could do something like this with a preprocessor 
but then you run into all sorts of other problems (i.e. #define 
safe  safe).

If you come up with other ideas then feel free to share.  No one 
likes the current state but no one has come up with a good 
solution yet.
Sep 22 2018
next sibling parent reply krzaq <dlangmailinglist krzaq.cc> writes:
On Saturday, 22 September 2018 at 20:40:14 UTC, Jonathan Marler 
wrote:

 On Saturday, 22 September 2018 at 19:04:41 UTC, Henrik wrote:

 [...]


 That works for types but wouldn't work for keywords. Keywords 
 have special meaning in the lexical stage and you can't 
 extend/change the grammar of the language via an alias or 
 typedef.  You could do something like this with a preprocessor 
 but then you run into all sorts of other problems (i.e. #define 
 safe  safe).

 If you come up with other ideas then feel free to share.  No 
 one likes the current state but no one has come up with a good 
 solution yet.


C++ added contextual keywords, like `override` and `final`. If 
this can be done in C++, surely D is easier to parse?
Sep 22 2018
next sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Saturday, 22 September 2018 at 20:53:02 UTC, krzaq wrote:

 C++ added contextual keywords, like `override` and `final`. If 
 this can be done in C++, surely D is easier to parse?


Currently this compiles:

alias safe = int;

 safe foo() { return 1; }
safe bar() { return 2; }

Making "safe" a keyword would cause the second definition to be 
ambiguous.

(Not that there's much incentive to keep this syntax valid...)
Sep 22 2018
prev sibling next sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
On Saturday, 22 September 2018 at 20:53:02 UTC, krzaq wrote:

 On Saturday, 22 September 2018 at 20:40:14 UTC, Jonathan Marler 
 wrote:

 On Saturday, 22 September 2018 at 19:04:41 UTC, Henrik wrote:

 [...]


 That works for types but wouldn't work for keywords. Keywords 
 have special meaning in the lexical stage and you can't 
 extend/change the grammar of the language via an alias or 
 typedef.  You could do something like this with a preprocessor 
 but then you run into all sorts of other problems (i.e. 
 #define safe  safe).

 If you come up with other ideas then feel free to share.  No 
 one likes the current state but no one has come up with a good 
 solution yet.


 C++ added contextual keywords, like `override` and `final`. If 
 this can be done in C++, surely D is easier to parse?


https://wiki.dlang.org/Language_Designs_Explained#Why_don.27t_we_create_a_special_rule_in_the_syntax_to_handle_non-keyword_function_attributes_without_an_.27.40.27_character.3F
Sep 22 2018
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 22 September 2018 at 20:53:02 UTC, krzaq wrote:

 C++ added contextual keywords, like `override` and `final`. If 
 this can be done in C++, surely D is easier to parse?


If D did more stuff like that, it would start to be harder to 
parse.
Sep 22 2018
prev sibling parent Henrik <henrik nothing.com> writes:
On Saturday, 22 September 2018 at 20:40:14 UTC, Jonathan Marler 
wrote:

 On Saturday, 22 September 2018 at 19:04:41 UTC, Henrik wrote:

 On Saturday, 22 September 2018 at 15:45:09 UTC, Jonathan 
 Marler wrote:

 On Saturday, 22 September 2018 at 15:25:32 UTC, aberba wrote:

 On Saturday, 22 September 2018 at 14:31:20 UTC, Jonathan 
 Marler wrote:

 On Saturday, 22 September 2018 at 13:25:27 UTC, rikki 
 cattermole wrote:

 Then D isn't the right choice for you.


 I think it makes for a better community if we can be more 
 welcoming, helpful a gracious instead of responding to 
 criticism this way. This is someone who saw enough 
 potential with D to end up on the forums but had some 
 gripes with it, after all who doesn't? I'm glad he took the 
 initiative to provide us with good feedback, and he's not 
 the first to take issue with the inconsistent ' ' attribute 
 syntax.  I'm sure everyone can agree this inconsistency is 
 less than ideal but that doesn't mean D isn't right for 
 them and we should respond this feedback like this with 
 thanks rather than dismissal.


 That inconsistency is an issue for me. I wish there a clear 
 decision to make things consistent.


 Yeah there's been alot of discussion around it over the 
 years, which is why I put this together about 4 years ago:

 https://wiki.dlang.org/Language_Designs_Explained#Function_attributes

 Gosh I've forgotten how long I've been using D.


 Interesting article.

 "int safe = 0; // This code would break if "safe" was added as 
 a keyword"

 My question here: why didn't D use a similar solution as C 
 when dealing with these things? Look at the introduction of 
 the bool datatype in C99. They created the compiler reserved 
 type "_Bool" and put "typedef _Bool bool" in "stdbool.h". The 
 people wanting to use this new feature can include this 
 header, and other can leave it be. No ugly " " polluting the 
 language on every line where it's used. Wouldn't a similar 
 solution have been possible in D?


 That works for types but wouldn't work for keywords. Keywords 
 have special meaning in the lexical stage and you can't 
 extend/change the grammar of the language via an alias or 
 typedef.  You could do something like this with a preprocessor 
 but then you run into all sorts of other problems (i.e. #define 
 safe  safe).

 If you come up with other ideas then feel free to share.  No 
 one likes the current state but no one has come up with a good 
 solution yet.


Yes, of course you are right. A typedef for this problem wouldn't 
be good enough. But there are plenty of other solutions to 
encapsulate the ugliness in one area instead of spreading it to 
every codeline. What about a compiler switch like the one in gcc? 
"-std=c11"? until making the change to default?

There is an excellent speech from Scott Meyers about this. I 
loved his books about C++, and his recommendations for D are just 
as good. 41:00 into the video he mentions the legacy crud of C++ 
and the accidental complexity it contains. He advises D to avoid 
the need of having "explainers" like him in the future, and to 
use the small legacy codebase in D to remove/avoid such 
accidental complexity.

https://www.youtube.com/watch?v=KAWA1DuvCnQ

I don't think enough people listened to him.
Sep 22 2018
prev sibling parent aliak <something something.com> writes:
On Saturday, 22 September 2018 at 19:04:41 UTC, Henrik wrote:

 On Saturday, 22 September 2018 at 15:45:09 UTC, Jonathan Marler 
 wrote:

 On Saturday, 22 September 2018 at 15:25:32 UTC, aberba wrote:

 [...]


 Yeah there's been alot of discussion around it over the years, 
 which is why I put this together about 4 years ago:

 https://wiki.dlang.org/Language_Designs_Explained#Function_attributes

 Gosh I've forgotten how long I've been using D.


 Interesting article.

 "int safe = 0; // This code would break if "safe" was added as 
 a keyword"


You don't have to turn the   words to non- s. You can go the 
other way and make attributes consistently use   as well and 
remove them as keywords.

So

pure void f() {} // Deprecated, attributes must start with
Sep 23 2018
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
This is just so reminiscent of the Python 2 / Python 3 fiasco.

Python 3 was clearly an improvement over Python 2, but the way in which the
changes came to the community caused a violent split. Even after many years=
,
there are those for whom Python 3 is anathema and not to be used.

The Python community has now moved on, and the Python 3 haters are just lef=
t
to their own devices. If they want to come to the community they have to be
accepting that Python 3 is the mainline and not try to undermine that.

The Python community is the most diverse and welcoming community of all the
programming communities I have ever been involved with. The 2/3 war is over=
, 3
is the one true way. Until 4 is released.

On Sat, 2018-09-22 at 14:31 +0000, Jonathan Marler via Digitalmars-d wrote:

 On Saturday, 22 September 2018 at 13:25:27 UTC, rikki cattermole=20
 wrote:

 Then D isn't the right choice for you.


=20
 I think it makes for a better community if we can be more=20
 welcoming, helpful a gracious instead of responding to criticism=20
 this way. This is someone who saw enough potential with D to end=20
 up on the forums but had some gripes with it, after all who=20
 doesn't? I'm glad he took the initiative to provide us with good=20
 feedback, and he's not the first to take issue with the=20
 inconsistent ' ' attribute syntax.  I'm sure everyone can agree=20
 this inconsistency is less than ideal but that doesn't mean D=20
 isn't right for them and we should respond this feedback like=20
 this with thanks rather than dismissal.


Someone did say, Use D 2 but without the cruft and it looks and feels like =
D1.
That seems like a constructive suggestion.

Perhaps D 2 can be improved by getting rid of the cruft and saying backward
compatibility is seriously over-rated.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Sep 22 2018
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Saturday, 22 September 2018 at 16:22:31 UTC, Russel Winder 
wrote:

 This is just so reminiscent of the Python 2 / Python 3 fiasco.

 Python 3 was clearly an improvement over Python 2, but the way 
 in which the changes came to the community caused a violent 
 split. Even after many years, there are those for whom Python 3 
 is anathema and not to be used.

 [...]


Have you followed the discussion of Jonathan on  implicit?
It seems that D2 is going in the opposite direction: more cruft 
is being added, for sake of (dubious) compatibility.
Sep 22 2018
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 23/09/2018 2:31 AM, Jonathan Marler wrote:

 On Saturday, 22 September 2018 at 13:25:27 UTC, rikki cattermole wrote:

 Then D isn't the right choice for you.


 
 I think it makes for a better community if we can be more welcoming, 
 helpful a gracious instead of responding to criticism this way. This is 
 someone who saw enough potential with D to end up on the forums but had 
 some gripes with it, after all who doesn't? I'm glad he took the 
 initiative to provide us with good feedback, and he's not the first to 
 take issue with the inconsistent ' ' attribute syntax.  I'm sure 
 everyone can agree this inconsistency is less than ideal but that 
 doesn't mean D isn't right for them and we should respond this feedback 
 like this with thanks rather than dismissal.


It's much better for the language and for the person looking into a 
technology to be open to saying that it isn't the right tool for the job 
after some discussion which has taken place.

I would much rather stop people looking instead of trying to impose 
changes on us that are not likely to happen in any acceptable time span. 
Let alone at all. At least then, they can look back and see that we 
didn't want to waste their or our time trying to compromise on something 
that wasn't going to happen anyway.

After all, don't we want to make people happy with their decision?
Sep 22 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, September 22, 2018 7:34:55 PM MDT rikki cattermole via 
Digitalmars-d wrote:

 On 23/09/2018 2:31 AM, Jonathan Marler wrote:

 On Saturday, 22 September 2018 at 13:25:27 UTC, rikki cattermole wrote:

 Then D isn't the right choice for you.


 I think it makes for a better community if we can be more welcoming,
 helpful a gracious instead of responding to criticism this way. This is
 someone who saw enough potential with D to end up on the forums but had
 some gripes with it, after all who doesn't? I'm glad he took the
 initiative to provide us with good feedback, and he's not the first to
 take issue with the inconsistent ' ' attribute syntax.  I'm sure
 everyone can agree this inconsistency is less than ideal but that
 doesn't mean D isn't right for them and we should respond this feedback
 like this with thanks rather than dismissal.


 It's much better for the language and for the person looking into a
 technology to be open to saying that it isn't the right tool for the job
 after some discussion which has taken place.

 I would much rather stop people looking instead of trying to impose
 changes on us that are not likely to happen in any acceptable time span.
 Let alone at all. At least then, they can look back and see that we
 didn't want to waste their or our time trying to compromise on something
 that wasn't going to happen anyway.

 After all, don't we want to make people happy with their decision?


We want to understand where D can and should be improved, but we also need
to acknowledge where it shouldn't be changed. Not everyone is going to be
happy with it, and we shouldn't try to make it so that everyone is going to
be happy with it. For instance, from what I know of Go, I would be
_extremely_ unhappy with it, and yet there are folks who absolutely love it.
Would I try to convince such folks to come to D? No. If that's the kind of
taste that they have in languages, I'd rather that they'd stay away from D
and not risk affecting it in a negative way for me. On the other hand, if D
fits reasonably well for someone but doesn't quite fit well enough due to
some problem with the language, then maybe there's something that we can do
to address that, making D work for them, and making it a better language for
the rest of us.

Ultimately, it's a question of balance. We want to improve D and make it
work for more people, but we also don't want to make it worse for ourselves
in the process of trying to make it work better for someone else. Listening
to complaints about the language from both those trying it out and those who
use it regularly can be important. Ultimately though, I think that it makes
a lot more sense to focus on trying to fix the problems that existing users
have rather than trying to fix the problems that potential users have. As
Walter likes to talk about, when someone tells you why they're not using
something, and you solve that problem for them, they always have another
reason. And really, while we want D to have a large user base, as users of
the language, first and foremost, we want it to work well for ourselves. If
we can make the language work really well for what we need, then it will
work well for other people as well, even if it won't work well for everyone.

With regards to D1 users who are unhappy with D2, I think that it makes some
sense to point out that a subset of D2 can be used in a way that's a lot
like D1, but ultimately, if someone doesn't like the direction that D2 took,
they're probably better off finding a language that better fits whatever it
is that they're looking for in a language. Trying to convince someone to use
a language that they don't like is likely to just make them unhappy.

- Jonathan M Davis
Sep 22 2018
parent reply Chris <wendlec tcd.ie> writes:
On Sunday, 23 September 2018 at 02:05:42 UTC, Jonathan M Davis 
wrote:


 With regards to D1 users who are unhappy with D2, I think that 
 it makes some sense to point out that a subset of D2 can be 
 used in a way that's a lot like D1, but ultimately, if someone 
 doesn't like the direction that D2 took, they're probably 
 better off finding a language that better fits whatever it is 
 that they're looking for in a language. Trying to convince 
 someone to use a language that they don't like is likely to 
 just make them unhappy.

 - Jonathan M Davis


I think the problem is that D2 added too many things too fast, 
often based on what was the latest CS/industry fashion of the 
day. I'm not saying that all the features are useless, I'm just 
saying that sometimes it's better to lean back for a while and 
have a cuppa before you add and complicate things further. Not 
all features that have been added are indispensable. I've 
recently made the experience that you can get very far very fast 
with a small and compact language that has useful features, 
features that have been proven to be useful in _everyday 
programming_ and were added for exactly this reason.

Posters on this thread have pointed out that one should avoid 
certain keywords and features, if one wants a simpler experience. 
However, the D community encourages people to use all the latest 
fancy features and idioms, which to a certain extent you have to 
do anyway if you use Phobos. So it's very confusing for newcomers 
and sometimes for longtime users too and your code ends up 
reflecting the various development stages of D2.

Maybe it's time for D3. Pick and choose the things that work and 
really do make sense and discard others that don't add much value 
but only bring trouble. I think D2 is a nice collection of Lego 
bricks by now that could be used to build something truly great.
Sep 24 2018
parent Meta <jared771 gmail.com> writes:
On Monday, 24 September 2018 at 09:19:34 UTC, Chris wrote:

 On Sunday, 23 September 2018 at 02:05:42 UTC, Jonathan M Davis 
 wrote:


 With regards to D1 users who are unhappy with D2, I think that 
 it makes some sense to point out that a subset of D2 can be 
 used in a way that's a lot like D1, but ultimately, if someone 
 doesn't like the direction that D2 took, they're probably 
 better off finding a language that better fits whatever it is 
 that they're looking for in a language. Trying to convince 
 someone to use a language that they don't like is likely to 
 just make them unhappy.

 - Jonathan M Davis


 Maybe it's time for D3. Pick and choose the things that work 
 and really do make sense and discard others that don't add much 
 value but only bring trouble. I think D2 is a nice collection 
 of Lego bricks by now that could be used to build something 
 truly great.


I don't agree; the time for D3 is still many years away. 
Transitiong to D3 now would be suboptimal, as the D2 language is 
still being "explored". The D community as a whole needs more 
experience with the language to understand pain points, so we can 
make more informed changes in D3 (if D3 ever happens; it may not 
need to).
Sep 24 2018
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/22/2018 10:31 AM, Jonathan Marler wrote:

 On Saturday, 22 September 2018 at 13:25:27 UTC, rikki cattermole wrote:

 Then D isn't the right choice for you.


 
 I think it makes for a better community if we can be more welcoming, 
 helpful a gracious instead of responding to criticism this way. This is 
 someone who saw enough potential with D to end up on the forums but had 
 some gripes with it, after all who doesn't? I'm glad he took the 
 initiative to provide us with good feedback, and he's not the first to 
 take issue with the inconsistent ' ' attribute syntax.  I'm sure 
 everyone can agree this inconsistency is less than ideal but that 
 doesn't mean D isn't right for them and we should respond this feedback 
 like this with thanks rather than dismissal.
 


Ordinarily yes, but most of what "new" has said above has been very 
trollish and borderline irrational.
Sep 25 2018
prev sibling parent reply Guillaume Piolat <spam smam.org> writes:
On Saturday, 22 September 2018 at 13:22:03 UTC, new wrote:

 On Saturday, 22 September 2018 at 10:53:25 UTC, bauss wrote:

 On Saturday, 22 September 2018 at 09:42:48 UTC, Jonathan 
 Marler wrote:

 I'd be interested to hear/read about the features that some 
 developers don't like with D2.


 I'm going to guess it has to do with all the attributes for 
 functions which you often have to remember is it  attribute or 
 is it just attribute like is it  nogc or is it nogc etc.

 It's one of the things that probably throws off a lot of new 
 users of D, because they feel like they __have__ to know those 
 although they're often optional and you can live without them 
 completely.

 They make the language seem bloated.


 the language is bloated. trying to read the source of D2 makes 
 gives you the feeling of getting eye cancer.
 so we decided if D at all then it should be D1.


Hello,

You can have a pretty much "D1" experience if you avoid new 
features:
-  nogc
- shared
- avoid constness (well except strings), inout
- alias bit = bool; // :)
- struct postblit
- etc..

AFAIK if you port D1 code the only problem is with 
immutable(char)[] instead of string, and the only thing to know 
is that immutable(T) and T implicitely convert to const(T).

D2 the language has become longer to learn, but there is a subset 
that is very much like D1. It's a matter of introducing features 
as you go, one by one.

A lot of things are objectively better like build systems, 
ecosystems, stability, meta-programming, CTFE, OPTLINK, Phobos...
Sep 23 2018
next sibling parent JN <666total wp.pl> writes:
On Sunday, 23 September 2018 at 13:55:02 UTC, Guillaume Piolat 
wrote:

 A lot of things are objectively better like build systems, 
 ecosystems, stability, meta-programming, CTFE, OPTLINK, 
 Phobos...


I wouldn't say meta-programming and CTFE are 'objectively' 
better. It could be argued that such features lengthen 
compilation time and make it harder to parse D code (thus harder 
to write tools for it).
Sep 23 2018
prev sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Sunday, 23 September 2018 at 13:55:02 UTC, Guillaume Piolat 
wrote:

 AFAIK if you port D1 code the only problem is with 
 immutable(char)[] instead of string, and the only thing to know 
 is that immutable(T) and T implicitely convert to const(T).


A lot of D1 code was 32-bit only, so there will be tons of uint 
instead of size_t.

Implicit string concatenation was also a thing. I tried porting 
Jarrett Billingsley's Croc (aka MiniD) to D2, and that was the 
most common issue I encountered.


 A lot of things are objectively better like build systems, 
 ecosystems, stability, meta-programming, CTFE, OPTLINK, 
 Phobos...


Most of the D1 ecosystem died with dsource.org, yes.

D1 code doesn't have a modern Phobos, but it does have Tango 
available, which might help.
Sep 23 2018
prev sibling next sibling parent new <new new.com> writes:
On Saturday, 22 September 2018 at 08:48:37 UTC, Nemanja Borić 
wrote:

 On Friday, 21 September 2018 at 21:07:57 UTC, Jonathan M Davis 
 wrote:

 [...]


 Sociomantic "maintains" (well, much more in the past than 
 today) D1 compiler and you can find latest releases here 
 (Ubuntu): https://bintray.com/sociomantic-tsunami/dlang/dmd1 
 (direct link 
 https://bintray.com/sociomantic-tsunami/dlang/dmd1/v1.082.1#files) or you can
compile https://github.com/dlang/dmd/tree/dmd-1.x yourself and hope that the
compiler bug is fixed - we've certainly fixed a lot of them in the past years
(decade?).

 [...]


Thank you for valuable info. i'll check that out.
Sep 22 2018
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2018-09-22 10:48, Nemanja Borić wrote:


 So it is possible to use D2 language and compiler and avoid all the 
 features that you don't like, at least to a reasonable degree, and as a 
 bonus you still get to cherry pick D2 features you like (and there are 
 some even for D1 minded person).


Yeah, for example, the DWT [1] code base use very few D2 features. It 
was originally written in D1 and then ported to D2 with as few changes 
as possible. It might actually still compile using a D1 compiler.

[1] https://github.com/d-widget-toolkit/dwt

-- 
/Jacob Carlborg
Sep 25 2018