www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Blog article on new import changes

reply Steven Schveighoffer <schveiguy yahoo.com> writes:
I anticipate 2.071.0 is going to cause a lot of deprecation messages and 
strange errors to occur, due to the fixes of very long-standing import bugs.

I wrote a blog post (actually my first ever) on this, let me know what 
you think (and please, any clarifications/errors, let me know):

http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/
Mar 29 2016
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer 
wrote:

 I anticipate 2.071.0 is going to cause a lot of deprecation 
 messages and strange errors to occur, due to the fixes of very 
 long-standing import bugs.

 I wrote a blog post (actually my first ever) on this, let me 
 know what you think (and please, any clarifications/errors, let 
 me know):

 http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


This is an informative article, good job.

Here are some notes I jotted down when reading it


In the newest version of D upcoming, several changes have been 
made to the import system, including fixes for 2 of the oldest 
bugs in D history.


Grammatically, it's redundant to put "upcoming" where it is; 
numbers under 20 are typically written with their name.


 However, until the fix was rendered, these module symbols were 
 imported as if they were marked public.


This sentence is redundant.


 This determines where the problem lies.


This sentence is also redundant.
Mar 29 2016
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/29/16 11:49 AM, Jack Stouffer wrote:

 Here are some notes I jotted down when reading it


Thanks, all fixed.

Note, the "upcoming" note was added hastily before publishing because I 
realized 2.071 hasn't been released.

Now reads:

"In the upcoming version of D, several changes have been made to the 
import system"
Mar 29 2016
prev sibling next sibling parent reply Dicebot <public dicebot.lv> writes:
On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer 
wrote:

 I anticipate 2.071.0 is going to cause a lot of deprecation 
 messages and strange errors to occur, due to the fixes of very 
 long-standing import bugs.

 I wrote a blog post (actually my first ever) on this, let me 
 know what you think (and please, any clarifications/errors, let 
 me know):

 http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


Worth mentioning that -transition=checkimports may slow down 
compilation notably which is why it isn't the default.
Mar 29 2016
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/29/16 1:01 PM, Dicebot wrote:

 On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer wrote:

 I anticipate 2.071.0 is going to cause a lot of deprecation messages
 and strange errors to occur, due to the fixes of very long-standing
 import bugs.

 I wrote a blog post (actually my first ever) on this, let me know what
 you think (and please, any clarifications/errors, let me know):

 http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


 Worth mentioning that -transition=checkimports may slow down compilation
 notably which is why it isn't the default.


Thanks, added a note.

-Steve
Mar 29 2016
prev sibling next sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer 
wrote:

 I anticipate 2.071.0 is going to cause a lot of deprecation 
 messages and strange errors to occur, due to the fixes of very 
 long-standing import bugs.

 I wrote a blog post (actually my first ever) on this, let me 
 know what you think (and please, any clarifications/errors, let 
 me know):

 http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


I would avoid 'generated' names like ex1_a and ex1_b, and go for 
something concrete. E.g.

module car;
import tire;

Or whatever.

Besided that, great and clear article.
Mar 29 2016
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/29/16 2:02 PM, Sebastiaan Koppe wrote:

 On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer wrote:

 I anticipate 2.071.0 is going to cause a lot of deprecation messages
 and strange errors to occur, due to the fixes of very long-standing
 import bugs.

 I wrote a blog post (actually my first ever) on this, let me know what
 you think (and please, any clarifications/errors, let me know):

 http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


 I would avoid 'generated' names like ex1_a and ex1_b, and go for
 something concrete. E.g.

 module car;
 import tire;


Yeah, I probably could.

I wanted all my code in one gist, so I tried to come up with examples I 
could compile all at once. Worked great like dmd ex1*.d :)

I'll see if I can change it, I agree it would sound better.


 Besided that, great and clear article.


Thanks

-Steve
Mar 29 2016
prev sibling next sibling parent reply xenon325 <anm programmer.net> writes:
On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer 
wrote:

 I anticipate 2.071.0 is going to cause a lot of deprecation 
 messages and strange errors to occur, due to the fixes of very 
 long-standing import bugs.

 I wrote a blog post (actually my first ever) on this, let me 
 know what you think (and please, any clarifications/errors, let 
 me know):

 http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


1.

 In addition, importing a module using static, renamed, or 
 selective imports, then the module was imported publicly, even 
 though it was supposed to be private.


Not an English speaker, but this doesn't sound right (at least 
stylistically).
Reread it several times, but I couldn't get the meaning of the 
sentence, until opened bug report.

2.

 With 2.070.2 and prior versions, compiling this works just 
 fine. With 2.071.0 and above, you will get either a deprecation 
 warning, or an error.



 With 2.070.2, this compiled just fine. [...] With 2.071.0 and 
 above, this will trigger a deprecation warning. In the future, 
 the code will trigger an error.



 In 2.070.2, this produces no warning or error. In 2.071.0 and 
 beyond, this will produce a deprecation warning, and eventually 
 an error.


Not sure if it's worth it to repeat after each example. Feels 
redundant.

3. I think it's OK to write just major compiler versions, no need 
for patch version: 2.070 and 2.071
Mar 29 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/29/16 11:08 PM, xenon325 wrote:

 On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer wrote:

 I anticipate 2.071.0 is going to cause a lot of deprecation messages
 and strange errors to occur, due to the fixes of very long-standing
 import bugs.

 I wrote a blog post (actually my first ever) on this, let me know what
 you think (and please, any clarifications/errors, let me know):

 http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


 1.

 In addition, importing a module using static, renamed, or selective
 imports, then the module was imported publicly, even though it was
 supposed to be private.


 Not an English speaker, but this doesn't sound right (at least
 stylistically).
 Reread it several times, but I couldn't get the meaning of the sentence,
 until opened bug report.


Definitely some grammar issues there. New reworded sentence:

In addition, when importing a module using static, renamed, or selective 
imports, the symbols imported were incorrectly made public to importing 
modules.

Sound better?


 2.

 With 2.070.2 and prior versions, compiling this works just fine. With
 2.071.0 and above, you will get either a deprecation warning, or an
 error.



 With 2.070.2, this compiled just fine. [...] With 2.071.0 and above,
 this will trigger a deprecation warning. In the future, the code will
 trigger an error.



 In 2.070.2, this produces no warning or error. In 2.071.0 and beyond,
 this will produce a deprecation warning, and eventually an error.


 Not sure if it's worth it to repeat after each example. Feels redundant.


I think it's important to state the previous and new behavior, even 
though it's always the same. It does sound redundant, but makes it 
easier to understand.


 3. I think it's OK to write just major compiler versions, no need for
 patch version: 2.070 and 2.071


Yes, I did that.

Thanks for the feedback.

-Steve
Mar 30 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/30/2016 5:58 AM, Steven Schveighoffer wrote:

 Thanks for the feedback.


And thanks for writing the article. Much appreciated.
Mar 30 2016
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/30/16 3:24 PM, Walter Bright wrote:

 On 3/30/2016 5:58 AM, Steven Schveighoffer wrote:

 Thanks for the feedback.


 And thanks for writing the article. Much appreciated.


You're welcome :)

-Steve
Mar 31 2016
prev sibling parent xenon325 <anm programmer.net> writes:
On Wednesday, 30 March 2016 at 12:58:00 UTC, Steven Schveighoffer 
wrote:

 Sound better?


Yeah, thanks.


 Not sure if it's worth it to repeat after each example. Feels 
 redundant.


 I think it's important to state the previous and new behavior, 
 even though it's always the same. It does sound redundant, but 
 makes it easier to understand.


That's reasonable. You could kinda "compress" this, however - 
full description on first occurrence and a brief one later on. 
This is a common practice AFAICT:


 With 2.070 and prior versions, compiling this works just fine. 
 With 2.071 and above, you will get either a deprecation 
 warning, or an error.


--> "With 2.070 and prior versions, compiling this works just 
fine. In 2.071 it's deprecated (meaning you will get a warning 
now and compilation error with some later version of the 
compiler)"


 With 2.070, this compiled just fine. However, printf is 
 supposed to be a private symbol of module ex2_a. With 2.071 and 
 above, this will trigger a deprecation warning. In the future, 
 the code will trigger an error.


--> "Fine with 2.070, deprecated in 2.071 because printf is 
supposed to be a private symbol of module ex2_a"


 In 2.070, this produces no warning or error. In 2.071 and 
 beyond, this will produce a deprecation warning, and eventually 
 an error.


--> "Fine with 2.070, deprecated in 2.071"


Anyway, not a big deal. Sorry if I've gone too far with 
nitpicking :) Thanks for the article!

-Alexander
Mar 31 2016
prev sibling next sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 03/29/2016 05:25 PM, Steven Schveighoffer wrote:

 I wrote a blog post (actually my first ever) on this, let me know what
 you think (and please, any clarifications/errors, let me know):
 
 http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


Thanks
Mar 30 2016
prev sibling parent "H. S. Teoh via Digitalmars-d-announce" writes:
On Tue, Mar 29, 2016 at 11:25:27AM -0400, Steven Schveighoffer via
Digitalmars-d-announce wrote:

 I anticipate 2.071.0 is going to cause a lot of deprecation messages
 and strange errors to occur, due to the fixes of very long-standing
 import bugs.
 
 I wrote a blog post (actually my first ever) on this, let me know what
 you think (and please, any clarifications/errors, let me know):
 
 http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


Excellent, thanks for writing this up!


T

-- 
Computers are like a jungle: they have monitor lizards, rams, mice, c-moss,
binary trees... and bugs.
Mar 30 2016