www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Beta 2.079.0

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Glad to announce the first beta for the 2.079.0 release, ♥ to the 77
contributors for this release.

http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.079.0.html

As usual please report any bugs at https://issues.dlang.org

- ----

This is probably the most feature-laden 2 month release ever.

Highlights:

https://dlang.org/changelog/2.079.0.html#lazy-gc-init
https://dlang.org/changelog/2.079.0.html#includeimports
https://dlang.org/changelog/2.079.0.html#minimal_runtime
https://dlang.org/changelog/2.079.0.html#toString

There is experimental ` nogc` exception throwing `-dip1008` (still
missing changelog).
Windows got a new experimental toolchain based on the lld linker and
MinGW import libraries. This will hopefully replace OMF in the
long-term without requiring heavy VC installations. Of course VC will
remain the primary toolchain on Windows. (still missing changelog)

A few remaining private symbols leaks have been fixed.
https://dlang.org/changelog/2.079.0.html#private
https://dlang.org/changelog/2.079.0.html#fix17630
https://dlang.org/changelog/2.079.0.html#fix18219

Some small syntax goodies:

https://dlang.org/changelog/2.079.0.html#multi_module_selective_imports
https://dlang.org/changelog/2.079.0.html#default_after_variadic

Some noteworthy deprecations:

https://dlang.org/changelog/2.079.0.html#deprecate_delete
https://dlang.org/changelog/2.079.0.html#hexstrings

- -Martin
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlqKq54ACgkQsnOBFhK7
GTlJwhAAh+gxo8dJDLulqdKk0EBPYcDvOLvllusp4Z1B+vCsmIZl7f6BhcVnYgfY
xXOCzTJkAPdGVk9h0VDs5J8Vq4WLlvrFgxw0R1KLBRe5NGOsUV2e48ZVkpspVaQM
DOuWnrjtfweSF+pK9fzr7HVDRnxd/oAiWzv/Qhl9Kcy5Uwh8wH6nUoMYxsX+IGpm
AZAJHVlhaf0X2YWA9B/q/BN6lqOl3yYlCN0waZEotkiYWXlWxumvEoDeJva9BWR6
3PZ6+t/UlJXuLpmbG6alivb9fnqXRief6YGpx2u41QcklnPfuqgyLvDLMosa/NV3
7u2/+qRgHLVwNRPGh24ywovciP8oOypoEZa7DkbrpgXphHgfPC9vvfKGGBBAd9ZW
SwKVKvGduq0ZGxFcsPZ+AdFnn0a+Qm2VOjRhHTxFUe11Mr9d+XBC797MN9RGy+2L
biNgtz0iKkIhGsqwH2fcNwAKSDAoaKs5sQfVzFa5Mz9vWkDLeBAtbUBCDGqiPjPJ
344YsI8ikpxfHZtcAf1p7a8gD272gEdFzZOuSlfVvTYQqKLMZzS2zHNoTMt/dK91
4tnr3qDDwqN9TC0VMHndtzu/rSKEHRRc8K1lUzS5KglqzGI4I18hSYMlij09qv6V
vTNdtv8TQafgNdR99o+yBY/N2HZlZOga5UDppffsghSX6jFnVOo=
=U7Zl
-----END PGP SIGNATURE-----
Feb 19
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to 
 the 77 contributors for this release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.079.0.html

 As usual please report any bugs at https://issues.dlang.org

 - ----

 This is probably the most feature-laden 2 month release ever.

 Highlights:

 https://dlang.org/changelog/2.079.0.html#lazy-gc-init 
 https://dlang.org/changelog/2.079.0.html#includeimports 
 https://dlang.org/changelog/2.079.0.html#minimal_runtime 
 https://dlang.org/changelog/2.079.0.html#toString

 There is experimental ` nogc` exception throwing `-dip1008` 
 (still
 missing changelog).
 Windows got a new experimental toolchain based on the lld 
 linker and
 MinGW import libraries. This will hopefully replace OMF in the
 long-term without requiring heavy VC installations. Of course 
 VC will
 remain the primary toolchain on Windows. (still missing 
 changelog)

 A few remaining private symbols leaks have been fixed. 
 https://dlang.org/changelog/2.079.0.html#private 
 https://dlang.org/changelog/2.079.0.html#fix17630 
 https://dlang.org/changelog/2.079.0.html#fix18219

 Some small syntax goodies:

 https://dlang.org/changelog/2.079.0.html#multi_module_selective_imports
https://dlang.org/changelog/2.079.0.html#default_after_variadic

 Some noteworthy deprecations:

 https://dlang.org/changelog/2.079.0.html#deprecate_delete 
 https://dlang.org/changelog/2.079.0.html#hexstrings

 - -Martin
Awesome. A typo. Lambda comparison using __traits(isSame, ...) ... Whenver ...
Feb 19
parent Seb <seb wilzba.ch> writes:
On Monday, 19 February 2018 at 11:21:34 UTC, Nicholas Wilson 
wrote:
 On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to 
 the 77 contributors for this release.
Awesome. A typo. Lambda comparison using __traits(isSame, ...) ... Whenver ...
... and A PR ;-) https://github.com/dlang/dmd/pull/7917 Thanks for spotting!
Feb 19
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 02/19/2018 05:49 AM, Martin Nowak wrote:
 http://dlang.org/changelog/2.079.0.html
...WOW O_o!!!! This release is seriously, just...wow! One question though: I'm unclear on the "include imports". Do those basically obviate the original purpose of rdmd? Ie, so dmd doesn't need to be passed a list of every individual file to be compiled? Just do this and be done?: $ dmd -offoobar -Isource -i=foobar source/foobar/main.d $ ./foobar Or do I misunderstand it?
Feb 19
next sibling parent bachmeier <no spam.net> writes:
On Monday, 19 February 2018 at 11:27:11 UTC, Nick Sabalausky 
(Abscissa) wrote:
 On 02/19/2018 05:49 AM, Martin Nowak wrote:
 http://dlang.org/changelog/2.079.0.html
...WOW O_o!!!! This release is seriously, just...wow! One question though: I'm unclear on the "include imports". Do those basically obviate the original purpose of rdmd? Ie, so dmd doesn't need to be passed a list of every individual file to be compiled? Just do this and be done?: $ dmd -offoobar -Isource -i=foobar source/foobar/main.d $ ./foobar Or do I misunderstand it?
That's a really nice feature to have buried in with all the other stuff. I didn't even notice it.
Feb 19
prev sibling parent Seb <seb wilzba.ch> writes:
On Monday, 19 February 2018 at 11:27:11 UTC, Nick Sabalausky 
(Abscissa) wrote:
 On 02/19/2018 05:49 AM, Martin Nowak wrote:
 http://dlang.org/changelog/2.079.0.html
...WOW O_o!!!! This release is seriously, just...wow! One question though: I'm unclear on the "include imports". Do those basically obviate the original purpose of rdmd? Ie, so dmd doesn't need to be passed a list of every individual file to be compiled? Just do this and be done?: $ dmd -offoobar -Isource -i=foobar source/foobar/main.d $ ./foobar Or do I misunderstand it?
Yes, you didn't misunderstand ;-) `-i` does the dependency resolution which was one of the main use cases for rdmd, but `rdmd` has "pivoted" over time and has still a few nice features: - caching - --eval & --loop - older compilers don't support -i (and IIRC Ian said that he isn't planning on adding it to gdc) -- --makedepend (Makefile dependency output) - shebang ... BTW in case someone is asking: "why was this required?". Try:
 rdmd -c -o- foo.d
--- pragma(msg, "Hello"); --- tl;dr: `rdmd` invokes dmd twice as it needs a first invocation to figure out which files to import. What the changelog entry sadly doesn't mention is that once -i has been integrated with rdmd, it will make rdmd about 30-40% faster (this integration has been moved to 2.080 as there were some concerns with compatibility of rdmd with older compilers)
Feb 19
prev sibling next sibling parent reply 9il <ilyayaroshenko gmail.com> writes:
On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to 
 the 77 contributors for this release.
Awesome! I like this release
Feb 19
parent Martin Tschierschke <mt smartdolphin.de> writes:
On Monday, 19 February 2018 at 11:29:04 UTC, 9il wrote:
 On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to 
 the 77 contributors for this release.
Awesome! I like this release
++ :-D
Feb 19
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to 
 the 77 contributors for this release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.079.0.html

 As usual please report any bugs at https://issues.dlang.org

 - ----

 This is probably the most feature-laden 2 month release ever.
I had noticed too that it will be a big release. But big release means more regression risk. Here's a first one: https://issues.dlang.org/show_bug.cgi?id=18469 Quite strangely the problem was not detected even if the stuff gets build and tested daily with the nightly on SemaphoreCI. Maybe something has not been "cherry picked" ?
Feb 19
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to 
 the 77 contributors for this release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.079.0.html

 As usual please report any bugs at https://issues.dlang.org

 - ----

 This is probably the most feature-laden 2 month release ever.
 ...
This looks good, but I'm not sure the many new features go well with the "2 month release" thing. I hope there are plans for a longer than usual testing period. Your announcement reads to me like it's going to be a regression bug release.
Feb 19
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 19 February 2018 at 15:45:30 UTC, bachmeier wrote:
 On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to 
 the 77 contributors for this release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.079.0.html

 As usual please report any bugs at https://issues.dlang.org

 - ----

 This is probably the most feature-laden 2 month release ever.
 ...
This looks good, but I'm not sure the many new features go well with the "2 month release" thing. I hope there are plans for a longer than usual testing period. Your announcement reads to me like it's going to be a regression bug release.
17. Allow multiple selective imports from different modules in a single import statement I have a bad feeling that that one is going to be a source of a raft of bugs for years to come.
Feb 19
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:

 17. Allow multiple selective imports from different modules in 
 a single import statement

 I have a bad feeling that that one is going to be a source of a 
 raft of bugs for years to come.
+1 I'm already hating it, after having read the change log example.
Feb 19
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
 17. Allow multiple selective imports from different modules in 
 a single import statement

 I have a bad feeling that that one is going to be a source of a 
 raft of bugs for years to come.
No need to use it if you don't like it. It's particularly useful for small examples, localized imports and hacking. It's mainly a generalisation of the existing possibility to mix module imports and one selective import at the end. If you prefer java-like 50 lines import manifests, then by all means keep using those. How would that feature cause bugs though?
Feb 20
next sibling parent Kagamin <spam here.lot> writes:
On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak wrote:
 If you prefer java-like 50 lines import manifests, then by all 
 means keep using those.
Imports can be written on one line. import std.stdio; import std.range; It only needs one more word.
Feb 20
prev sibling next sibling parent reply John Gabriele <jgabriele fastmail.fm> writes:
On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak wrote:
 On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
 17. Allow multiple selective imports from different modules in 
 a single import statement

 I have a bad feeling that that one is going to be a source of 
 a raft of bugs for years to come.
No need to use it if you don't like it. It's particularly useful for small examples, localized imports and hacking. It's mainly a generalisation of the existing possibility to mix module imports and one selective import at the end. If you prefer java-like 50 lines import manifests, then by all means keep using those. How would that feature cause bugs though?
In: import myModule : foo, bar; how do you know if bar is myModule.bar or if it's a separate module bar?
Feb 20
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 20 February 2018 at 19:36:46 UTC, John Gabriele wrote:
 In:

     import myModule : foo, bar;

 how do you know if bar is myModule.bar or if it's a separate 
 module bar?
It probably could be described a little better in the change log. It uses examples, but doesn't really describe what the file structure is that work with those examples. Perhaps this: --- pkg.d module pkg; public import pkg.mod1; public import pkg.mod2; --- pkg.mod1.d module pkg.mod1; enum sym1; --- pkg.mod2.d module pkg.mod2; enum sym2; If this structure works for both of those examples, then import pkg.mod1 : sym1, mod2 : sym2; works because mod2 has a selective import and import pkg.mod1 : sym1, sym2, pkg.mod2; works because pkg.mod2 is fully qualified (it may be annoying to find sym2 if this works with the above structure). So in your example you know that bar is in myModule because bar is neither fully qualified, nor is it fully qualified. So it seems like something below would also work import pkg : mod1 : sym1, mod2 : sym2; but then what about import pkg.mod1 : sym1, mod2 : sym2, sym3; Is sym3 part of mod1 or mod2?
Feb 20
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 20 February 2018 at 20:08:55 UTC, jmh530 wrote:
 So in your example you know that bar is in myModule because bar 
 is neither fully qualified, nor is it fully qualified.
*nor does it have selective imports.
Feb 20
parent Timothee Cour <thelastmammoth gmail.com> writes:
so how does one enforce that it imports `bar` as a module and not a
symbol in myModule when doing `import myModule : foo, bar;` ?
could this be supported:
`import myModule : foo, bar :`;
to break ambiguity?



On Tue, Feb 20, 2018 at 12:10 PM, jmh530 via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:
 On Tuesday, 20 February 2018 at 20:08:55 UTC, jmh530 wrote:
 So in your example you know that bar is in myModule because bar is neither
 fully qualified, nor is it fully qualified.
*nor does it have selective imports.
Feb 20
prev sibling parent reply John Gabriele <jgabriele fastmail.fm> writes:
On Tuesday, 20 February 2018 at 20:08:55 UTC, jmh530 wrote:
 On Tuesday, 20 February 2018 at 19:36:46 UTC, John Gabriele 
 wrote:
 In:

     import myModule : foo, bar;

 how do you know if bar is myModule.bar or if it's a separate 
 module bar?
It probably could be described a little better in the change log. It uses examples, but doesn't really describe what the file structure is that work with those examples. Perhaps this: --- pkg.d module pkg; public import pkg.mod1; public import pkg.mod2; --- pkg.mod1.d module pkg.mod1; enum sym1; --- pkg.mod2.d module pkg.mod2; enum sym2; If this structure works for both of those examples, then import pkg.mod1 : sym1, mod2 : sym2; works because mod2 has a selective import and import pkg.mod1 : sym1, sym2, pkg.mod2; works because pkg.mod2 is fully qualified (it may be annoying to find sym2 if this works with the above structure).
Thanks. Is the point to be able to string a bunch of selective imports together, as in: import pkg.mod1 : sym1, sym2, pkg.mod2 : sym1, sym2, pkg.mod3 : sym1; ? That's difficult to read; it's hard to see the difference between the commas that separate the symbols vs the commas that separate the modules+symbols groups.
Feb 20
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 20, 2018 at 10:19:03PM +0000, John Gabriele via
Digitalmars-d-announce wrote:
[...]
 Thanks. Is the point to be able to string a bunch of selective imports
 together, as in:
 
     import pkg.mod1 : sym1, sym2, pkg.mod2 : sym1, sym2, pkg.mod3 : sym1;
 
 ?
 
 That's difficult to read; it's hard to see the difference between the
 commas that separate the symbols vs the commas that separate the
 modules+symbols groups.
Yeah, personally I'd avoid writing it that way too. But obviously enough people like this syntax to push it through. *shrug* T -- Nobody is perfect. I am Nobody. -- pepoluan, GKC forum
Feb 20
next sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote:
 Yeah, personally I'd avoid writing it that way too.
There's no other way to use this feature though.
Feb 21
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, February 21, 2018 10:04:01 Kagamin via Digitalmars-d-announce 
wrote:
 On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote:
 Yeah, personally I'd avoid writing it that way too.
There's no other way to use this feature though.
Some of us think that it's a bad feature and have no intention of ever using it, though once it's in the language, we all have to worry about dealing with code that does use it. - Jonathan M Davis
Feb 21
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 21 February 2018 at 10:15:48 UTC, Jonathan M Davis 
wrote:
 On Wednesday, February 21, 2018 10:04:01 Kagamin via 
 Digitalmars-d-announce wrote:
 On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote:
 Yeah, personally I'd avoid writing it that way too.
There's no other way to use this feature though.
Some of us think that it's a bad feature and have no intention of ever using it, though once it's in the language, we all have to worry about dealing with code that does use it. - Jonathan M Davis
Was there a DIP for that? /Paolo
Feb 21
next sibling parent reply Eugene Wissner <belka caraus.de> writes:
On Wednesday, 21 February 2018 at 10:24:41 UTC, Paolo Invernizzi 
wrote:
 On Wednesday, 21 February 2018 at 10:15:48 UTC, Jonathan M 
 Davis wrote:
 On Wednesday, February 21, 2018 10:04:01 Kagamin via 
 Digitalmars-d-announce wrote:
 On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh 
 wrote:
 Yeah, personally I'd avoid writing it that way too.
There's no other way to use this feature though.
Some of us think that it's a bad feature and have no intention of ever using it, though once it's in the language, we all have to worry about dealing with code that does use it. - Jonathan M Davis
Was there a DIP for that? /Paolo
https://issues.dlang.org/show_bug.cgi?id=13855 https://github.com/dlang/dmd/pull/6589
Feb 21
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 21 February 2018 at 10:47:45 UTC, Eugene Wissner 
wrote:
 On Wednesday, 21 February 2018 at 10:24:41 UTC, Paolo 
 Invernizzi wrote:
 On Wednesday, 21 February 2018 at 10:15:48 UTC, Jonathan M 
 Davis wrote:
 On Wednesday, February 21, 2018 10:04:01 Kagamin via 
 Digitalmars-d-announce wrote:
 On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh 
 wrote:
 Yeah, personally I'd avoid writing it that way too.
There's no other way to use this feature though.
Some of us think that it's a bad feature and have no intention of ever using it, though once it's in the language, we all have to worry about dealing with code that does use it. - Jonathan M Davis
Was there a DIP for that? /Paolo
https://issues.dlang.org/show_bug.cgi?id=13855 https://github.com/dlang/dmd/pull/6589
And here we are again.
Feb 21
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, February 21, 2018 10:24:41 Paolo Invernizzi via Digitalmars-d-
announce wrote:
 On Wednesday, 21 February 2018 at 10:15:48 UTC, Jonathan M Davis

 wrote:
 On Wednesday, February 21, 2018 10:04:01 Kagamin via

 Digitalmars-d-announce wrote:
 On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote:
 Yeah, personally I'd avoid writing it that way too.
There's no other way to use this feature though.
Some of us think that it's a bad feature and have no intention of ever using it, though once it's in the language, we all have to worry about dealing with code that does use it.
Was there a DIP for that?
No, and I have no idea whether Walter approved of it or knows anything about it. He may be fine with it, or it may be that another compiler dev merged it, and he didn't notice. The list of DIPs is here, and this definitely isn't one of them: https://github.com/dlang/DIPs/tree/master/DIPs When suggestions like this have come up in the past, some of us have been against the idea, and others have loved the idea, but until this beta was released, I had no idea that anyone had actually gone and implemented it. - Jonathan M Davis
Feb 21
parent aberba <karabutaworld gmail.com> writes:
On Wednesday, 21 February 2018 at 10:54:11 UTC, Jonathan M Davis 
wrote:
 On Wednesday, February 21, 2018 10:24:41 Paolo Invernizzi via 
 Digitalmars-d- announce wrote:
 On Wednesday, 21 February 2018 at 10:15:48 UTC, Jonathan M 
 Davis

 wrote:
 [...]
Was there a DIP for that?
No, and I have no idea whether Walter approved of it or knows anything about it. He may be fine with it, or it may be that another compiler dev merged it, and he didn't notice. The list of DIPs is here, and this definitely isn't one of them: https://github.com/dlang/DIPs/tree/master/DIPs When suggestions like this have come up in the past, some of us have been against the idea, and others have loved the idea, but until this beta was released, I had no idea that anyone had actually gone and implemented it. - Jonathan M Davis
Face palm. Hmm.
Feb 22
prev sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Wednesday, 21 February 2018 at 10:15:48 UTC, Jonathan M Davis 
wrote:
 On Wednesday, February 21, 2018 10:04:01 Kagamin via 
 Digitalmars-d-announce wrote:
 On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote:
 Yeah, personally I'd avoid writing it that way too.
There's no other way to use this feature though.
Some of us think that it's a bad feature and have no intention of ever using it, though once it's in the language, we all have to worry about dealing with code that does use it. - Jonathan M Davis
+1000 how on earth can anyone approve, that syntax like that, can become part of the D Programming language? I'm really bewildered. Syntax is EVERYTHING. It can make or break a language.
Feb 21
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 21, 2018 at 02:46:56PM +0000, psychoticRabbit via
Digitalmars-d-announce wrote:
[...]
 Syntax is EVERYTHING. It can make or break a language.
And semantics doesn't matter. :-D T -- Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry
Feb 21
parent reply psychoticRabbit <meagain meagain.com> writes:
On Wednesday, 21 February 2018 at 16:58:22 UTC, H. S. Teoh wrote:
 On Wed, Feb 21, 2018 at 02:46:56PM +0000, psychoticRabbit via 
 Digitalmars-d-announce wrote: [...]
 Syntax is EVERYTHING. It can make or break a language.
And semantics doesn't matter. :-D T
assert("easy on the eyes" == "easy on the brain"); wtf! I get an assertion failure?? programming languages are just dumb tools to write syntax ;-) the semantics are in a different domain.
Feb 21
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 22, 2018 at 02:06:20AM +0000, psychoticRabbit via
Digitalmars-d-announce wrote:
 On Wednesday, 21 February 2018 at 16:58:22 UTC, H. S. Teoh wrote:
 On Wed, Feb 21, 2018 at 02:46:56PM +0000, psychoticRabbit via
 Digitalmars-d-announce wrote: [...]
 Syntax is EVERYTHING. It can make or break a language.
And semantics doesn't matter. :-D
[...]
 assert("easy on the eyes" == "easy on the brain");
Therein lies the rub: "easy on the eyes" is subjective. Meaning that reasonable people will disagree on what exactly constitutes "easy on the eyes". I'm pretty sure a Lisp geek would consider Lisp as very easy to read, and everything else as an eyesore. Does that mean everyone should use Lisp syntax to the exclusion of all else? I hope not.
 wtf! I get an assertion failure??
See, even dmd agrees with me. :-D
 programming languages are just dumb tools to write syntax ;-)
In Soviet Russia, programming languages write your syntax for you!
 the semantics are in a different domain.
Meaning, semantics are outside the domain of programming languages? That's ... an intriguing idea. I would like to subscribe to your newsletter. :-D T -- Just because you survived after you did it, doesn't mean it wasn't stupid!
Feb 22
prev sibling parent reply rjframe <dlang ryanjframe.com> writes:
On Wed, 21 Feb 2018 14:46:56 +0000, psychoticRabbit wrote:

 how on earth can anyone approve, that syntax like that, can become part
 of the D Programming language?
 
 I'm really bewildered.
 
 Syntax is EVERYTHING. It can make or break a language.
It does make sense in moderation for quick scripts, examples, blog posts, etc., where you want to showcase your actual code, not draw attention to the list of imports. Though with the std.scripting (or whatever it was) now, it's perhaps less useful for some of these. But it likely shouldn't be used in "real" applications; in particular, I think it would be nice for the Phobos style guide to restrict/disallow its use.
Feb 21
next sibling parent Uknown <sireeshkodali1 gmail.com> writes:
On Wednesday, 21 February 2018 at 18:10:51 UTC, rjframe wrote:
 On Wed, 21 Feb 2018 14:46:56 +0000, psychoticRabbit wrote:
 [snip]

 But it likely shouldn't be used in "real" applications; in 
 particular, I think it would be nice for the Phobos style guide 
 to restrict/disallow its use.
But whats the point of introducing a new feature and then restricting its use? Seems like feature itself is buggy or incorrectly implemented then
Feb 22
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, February 21, 2018 18:10:51 rjframe via Digitalmars-d-announce 
wrote:
 On Wed, 21 Feb 2018 14:46:56 +0000, psychoticRabbit wrote:
 how on earth can anyone approve, that syntax like that, can become part
 of the D Programming language?

 I'm really bewildered.

 Syntax is EVERYTHING. It can make or break a language.
It does make sense in moderation for quick scripts, examples, blog posts, etc., where you want to showcase your actual code, not draw attention to the list of imports. Though with the std.scripting (or whatever it was) now, it's perhaps less useful for some of these. But it likely shouldn't be used in "real" applications; in particular, I think it would be nice for the Phobos style guide to restrict/disallow its use.
If the concern is scripts, odds are that unless it made a significant difference in compilation time, it would just be better to import the modules without selective imports rather than trying to condense the selective imports into as little space as possible, killing legibility in the process. - Jonathan M Davis
Feb 22
prev sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Wednesday, 21 February 2018 at 18:10:51 UTC, rjframe wrote:
 But it likely shouldn't be used in "real" applications; in 
 particular, I think it would be nice for the Phobos style guide 
 to restrict/disallow its use.
grrr! better we get some common sense when implementing new stuff ;-) import std.stdio:write,writeln,writefln & std.array:join,split,replicate; vs import std.stdio:write,writeln,writefln,std.array:join,split,replicate; one is (AFAICT) already implemented, one is not. one is easy on the eyes (and therefore the brain), and one is not. one I would actually use, one I would not. one I would be ok for others to use, one I would not. can you guess which one applies to each case?
Feb 22
next sibling parent reply Timothee Cour <thelastmammoth gmail.com> writes:
you should also mention an important point:
current syntax disallows importing a simple module foo (with no package), eg:

import std.stdio:write,foo; // there's no way to specify a module `foo`
import std.stdio:write & foo; // ok

I don't care whether it's `|` or `&` but `,` as a module separator is
100% broken (and illegible, as you mentioned).




On Thu, Feb 22, 2018 at 12:42 AM, psychoticRabbit via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:
 On Wednesday, 21 February 2018 at 18:10:51 UTC, rjframe wrote:
 But it likely shouldn't be used in "real" applications; in particular, I
 think it would be nice for the Phobos style guide to restrict/disallow its
 use.
grrr! better we get some common sense when implementing new stuff ;-) import std.stdio:write,writeln,writefln & std.array:join,split,replicate; vs import std.stdio:write,writeln,writefln,std.array:join,split,replicate; one is (AFAICT) already implemented, one is not. one is easy on the eyes (and therefore the brain), and one is not. one I would actually use, one I would not. one I would be ok for others to use, one I would not. can you guess which one applies to each case?
Feb 22
next sibling parent reply aliak <something something.com> writes:
On Thursday, 22 February 2018 at 08:52:21 UTC, Timothee Cour 
wrote:
 you should also mention an important point:
 current syntax disallows importing a simple module foo (with no 
 package), eg:

 import std.stdio:write,foo; // there's no way to specify a 
 module `foo` import std.stdio:write & foo; // ok

 I don't care whether it's `|` or `&` but `,` as a module 
 separator is 100% broken (and illegible, as you mentioned).
Given that comma is implemented already, and barring a revert, can we maybe somewhat unbreak it by allowing: import mod1: write, .mod2; So leading dot to say it's a module (if not fully qualified)
Feb 22
next sibling parent reply Seb <seb wilzba.ch> writes:
On Thursday, 22 February 2018 at 13:35:00 UTC, aliak wrote:
 barring a revert,
Who says we can't revert it? https://github.com/dlang/dmd/pull/7939 On the contrary, imho if it's so controversial it should be reverted now, s.t. it doesn't accidentally end up in 2.079 and we would be stuck with it for a long time.
Feb 22
parent aliak <something something.com> writes:
On Thursday, 22 February 2018 at 13:51:18 UTC, Seb wrote:
 On Thursday, 22 February 2018 at 13:35:00 UTC, aliak wrote:
 barring a revert,
Who says we can't revert it? https://github.com/dlang/dmd/pull/7939 On the contrary, imho if it's so controversial it should be reverted now, s.t. it doesn't accidentally end up in 2.079 and we would be stuck with it for a long time.
Touche :) Though personally I'm actually not against the existence of the syntax. I think it does improve signal to noise ration if (like many language features) used correctly. And that it feels natural to expect it to work.
Feb 22
prev sibling parent psychoticRabbit <meagain meagain.com> writes:
On Thursday, 22 February 2018 at 13:35:00 UTC, aliak wrote:
 Given that comma is implemented already, and barring a revert, 
 can we maybe somewhat unbreak it by allowing:

 import mod1: write, .mod2;

 So leading dot to say it's a module (if not fully qualified)
leading dots?? grr!! I doubt change can be easier, clearer, or nicer to look at, than: import std.rabbit [food, water], std.house, std.family [carer]; I would support that syntax 100%. Nothing else I've seen would get that level of support from me.
Feb 22
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Thursday, 22 February 2018 at 08:52:21 UTC, Timothee Cour 
wrote:
 you should also mention an important point:
 current syntax disallows importing a simple module foo (with no 
 package), eg:

 import std.stdio:write,foo; // there's no way to specify a 
 module `foo` import std.stdio:write & foo; // ok

 I don't care whether it's `|` or `&` but `,` as a module 
 separator is 100% broken (and illegible, as you mentioned).
There is a better one ; . It forces to repeat import but one can not have everything :-)
Feb 22
prev sibling parent psychoticRabbit <meagain meagain.com> writes:
On Thursday, 22 February 2018 at 08:42:12 UTC, psychoticRabbit 
wrote:
 import std.stdio:write,writeln,writefln & 
 std.array:join,split,replicate;
 vs
 import 
 std.stdio:write,writeln,writefln,std.array:join,split,replicate;
and the rule would be simple. you can import modules on a single line, seperating each with a comma. however, an & instead of a comma seperates selective imports from the subsequent import. import std.stdio, std.algoritm: goDoStuff, goDoMoreStuff & std.conv, std.whatever; actually, the more I do that, the less I like it. I would still prefer selective imports to be on their own line: import std.stdio, std.conv, std.whatever; import std.algoritm : goDoStuff, goDoMoreStuff; but in simple case I might use it all on one line: import std.stdio: write, writeln & std.algorithm: doStuff, doSomeOtherStuff; but once introduced, programmers will misuse it - guaranteed. then will just be spending more of our time deciphering import statements.
Feb 22
prev sibling next sibling parent Suliman <evermind live.ru> writes:
On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote:
 On Tue, Feb 20, 2018 at 10:19:03PM +0000, John Gabriele via 
 Digitalmars-d-announce wrote: [...]
 Thanks. Is the point to be able to string a bunch of selective 
 imports together, as in:
 
     import pkg.mod1 : sym1, sym2, pkg.mod2 : sym1, sym2, 
 pkg.mod3 : sym1;
 
 ?
 
 That's difficult to read; it's hard to see the difference 
 between the commas that separate the symbols vs the commas 
 that separate the modules+symbols groups.
Yeah, personally I'd avoid writing it that way too. But obviously enough people like this syntax to push it through. *shrug*
I also dislike this import syntax
Feb 21
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote:
 On Tue, Feb 20, 2018 at 10:19:03PM +0000, John Gabriele via 
 Digitalmars-d-announce wrote: [...]
 Thanks. Is the point to be able to string a bunch of selective 
 imports together, as in:
 
     import pkg.mod1 : sym1, sym2, pkg.mod2 : sym1, sym2, 
 pkg.mod3 : sym1;
 
 ?
 
 That's difficult to read; it's hard to see the difference 
 between the commas that separate the symbols vs the commas 
 that separate the modules+symbols groups.
Yeah, personally I'd avoid writing it that way too. But obviously enough people like this syntax to push it through. *shrug* T
I'm going to a) never write these imports and b) pretend this feature doesn't exist. Atila
Feb 22
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, February 22, 2018 09:42:47 Atila Neves via Digitalmars-d-
announce wrote:
 On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote:
 On Tue, Feb 20, 2018 at 10:19:03PM +0000, John Gabriele via
 Digitalmars-d-announce wrote: [...]

 Thanks. Is the point to be able to string a bunch of selective

 imports together, as in:
     import pkg.mod1 : sym1, sym2, pkg.mod2 : sym1, sym2,

 pkg.mod3 : sym1;

 ?

 That's difficult to read; it's hard to see the difference
 between the commas that separate the symbols vs the commas
 that separate the modules+symbols groups.
Yeah, personally I'd avoid writing it that way too. But obviously enough people like this syntax to push it through. *shrug* T
I'm going to a) never write these imports and b) pretend this feature doesn't exist.
Me as well, but unfortunately, if someone uses it in code that you have to deal with, then you can't completely ignore its existence, which is why the argument that "it shouldn't matter if a feature is added that you don't want to use, because you don't have to use it if you don't want to" is bunk. Once a feature is in the language, it affects you even if you never use it. :| - Jonathan M Davis
Feb 22
parent reply Uknown <sireeshkodali1 gmail.com> writes:
On Thursday, 22 February 2018 at 09:48:20 UTC, Jonathan M Davis 
wrote:
 On Thursday, February 22, 2018 09:42:47 Atila Neves via 
 Digitalmars-d- announce wrote:
 On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote:
 On Tue, Feb 20, 2018 at 10:19:03PM +0000, John Gabriele via 
 Digitalmars-d-announce wrote: [...]

 [snip]
Once a feature is in the language, it affects you even if you never use it. :|
Which is why we should not let it pass. Why didn't this feature go through the usual DIP process?
Feb 22
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, February 22, 2018 09:54:17 Uknown via Digitalmars-d-announce 
wrote:
 On Thursday, 22 February 2018 at 09:48:20 UTC, Jonathan M Davis

 wrote:
 On Thursday, February 22, 2018 09:42:47 Atila Neves via

 Digitalmars-d- announce wrote:
 On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote:
 On Tue, Feb 20, 2018 at 10:19:03PM +0000, John Gabriele via
 Digitalmars-d-announce wrote: [...]

 [snip]
Once a feature is in the language, it affects you even if you never use it. :|
Which is why we should not let it pass. Why didn't this feature go through the usual DIP process?
All I can say for sure is what was said in the PR linked in another post: https://github.com/dlang/dmd/pull/6589 Based on the comments in the PR, Walter initially opposed it because he didn't like how it looked, but he said nothing after that. However, later, Andrei comments on the PR and thought that it was simply a fix for the current syntax and that it didn't need a DIP and thus approved it. I have no idea if he talked to Walter about it or not, but there is nothing in the PR to indicate that Walter ever changed his mind. This language change does not appear to have gone through much discussion either. Basically, Martin thought that it was a significant improvement and thus created a PR for it. Walter didn't like it but didn't close it. Almost 10 months later, Andrei sees it and decides that it's a small change which fixes a problem with the syntax and approves it and merges it, clearly thinking that it's not a big deal at all. - Jonathan M Davis
Feb 22
parent Joakim <dlang joakim.fea.st> writes:
On Thursday, 22 February 2018 at 10:07:40 UTC, Jonathan M Davis 
wrote:
 On Thursday, February 22, 2018 09:54:17 Uknown via 
 Digitalmars-d-announce wrote:
 On Thursday, 22 February 2018 at 09:48:20 UTC, Jonathan M Davis

 wrote:
 [...]
Which is why we should not let it pass. Why didn't this feature go through the usual DIP process?
All I can say for sure is what was said in the PR linked in another post: https://github.com/dlang/dmd/pull/6589 Based on the comments in the PR, Walter initially opposed it because he didn't like how it looked, but he said nothing after that. However, later, Andrei comments on the PR and thought that it was simply a fix for the current syntax and that it didn't need a DIP and thus approved it. I have no idea if he talked to Walter about it or not, but there is nothing in the PR to indicate that Walter ever changed his mind.
Heh, I just looked at who voted for and against in the first comment, by pressing and holding each icon, and it shows Walter voting both for and against it! :D
Feb 22
prev sibling parent reply psychoticRabboit <meagain meagain.com> writes:
On Thursday, 22 February 2018 at 09:42:47 UTC, Atila Neves wrote:
 I'm going to a) never write these imports and b) pretend this 
 feature doesn't exist.

 Atila
what about something like this then? import std.stdio; std.conv: to, from; std.algorithm: doSomething; std.whatever; just one simple rule; multiple imports on a line are seperated with ; surely the parser or whatever it's called, could work with that clean and simple solution.
Feb 22
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, February 22, 2018 10:30:44 psychoticRabboit via Digitalmars-d-
announce wrote:
 On Thursday, 22 February 2018 at 09:42:47 UTC, Atila Neves wrote:
 I'm going to a) never write these imports and b) pretend this
 feature doesn't exist.

 Atila
what about something like this then? import std.stdio; std.conv: to, from; std.algorithm: doSomething; std.whatever; just one simple rule; multiple imports on a line are seperated with ; surely the parser or whatever it's called, could work with that clean and simple solution.
Honestly, I'm against importing multiple modules on a single line just like I'm against putting multiple variable declarations on a single line. They're harder to read and easier to screw up. - Jonathan M Davis
Feb 22
parent reply Zoadian <no no.no> writes:
On Thursday, 22 February 2018 at 10:42:33 UTC, Jonathan M Davis 
wrote:
 On Thursday, February 22, 2018 10:30:44 psychoticRabboit via 
 Digitalmars-d- announce wrote:
 On Thursday, 22 February 2018 at 09:42:47 UTC, Atila Neves 
 wrote:
 I'm going to a) never write these imports and b) pretend this
 feature doesn't exist.

 Atila
what about something like this then? import std.stdio; std.conv: to, from; std.algorithm: doSomething; std.whatever; just one simple rule; multiple imports on a line are seperated with ; surely the parser or whatever it's called, could work with that clean and simple solution.
Honestly, I'm against importing multiple modules on a single line just like I'm against putting multiple variable declarations on a single line. They're harder to read and easier to screw up. - Jonathan M Davis
+1 I agree 100%
Feb 22
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 22, 2018 at 09:42:13PM +0000, Zoadian via Digitalmars-d-announce
wrote:
 On Thursday, 22 February 2018 at 10:42:33 UTC, Jonathan M Davis wrote:
 On Thursday, February 22, 2018 10:30:44 psychoticRabboit via
[...]
 what about something like this then?
 
 import std.stdio; std.conv: to, from; std.algorithm: doSomething;
 std.whatever;
 
 just one simple rule; multiple imports on a line are seperated with
 ;
 
 surely the parser or whatever it's called, could work with that
 clean and simple solution.
No it cannot. There's an ambiguity here: does the ';' mean the end of the import statement, or a delimiter between multiple modules? ';' cannot be used for this purpose.
 Honestly, I'm against importing multiple modules on a single line
 just like I'm against putting multiple variable declarations on a
 single line. They're harder to read and easier to screw up.
[...]
 +1
 I agree 100%
[...] +1. I agree 200%. It's an eyesore, hard to read, easy to screw up, and worst of all, *completely unnecessary*. There's nothing new it offers that we cannot already do, and it's just adding redundant syntax for marginal benefit (if even). I'm a little disappointed that a change like this got in, whereas something that's actually helpful, like DIP 1009, is sitting in limbo. T -- My program has no bugs! Only undocumented features...
Feb 22
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/22/2018 1:56 PM, H. S. Teoh wrote:
 I'm a little disappointed that a change like this got in, whereas
 something that's actually helpful, like DIP 1009, is sitting in limbo.
It's always true that trivia attracts far more attention and far more emotion than issues that require effort to understand.
Feb 22
parent reply psychoticRabbit <meagain meagain.com> writes:
On Friday, 23 February 2018 at 00:14:21 UTC, Walter Bright wrote:
 On 2/22/2018 1:56 PM, H. S. Teoh wrote:
 I'm a little disappointed that a change like this got in, 
 whereas
 something that's actually helpful, like DIP 1009, is sitting 
 in limbo.
It's always true that trivia attracts far more attention and far more emotion than issues that require effort to understand.
Umm...this requires effort to understand (much more than it should) : import pkg.mod1 : sym1, sym2, pkg.mod2 : sym1, sym2, pkg.mod3 : sym1; Can anyone see why this created attention?
Feb 22
parent psychoticRabbit <meagain meagain.com> writes:
On Friday, 23 February 2018 at 00:47:10 UTC, psychoticRabbit 
wrote:
 On Friday, 23 February 2018 at 00:14:21 UTC, Walter Bright 
 wrote:
 On 2/22/2018 1:56 PM, H. S. Teoh wrote:
 I'm a little disappointed that a change like this got in, 
 whereas
 something that's actually helpful, like DIP 1009, is sitting 
 in limbo.
It's always true that trivia attracts far more attention and far more emotion than issues that require effort to understand.
Umm...this requires effort to understand (much more than it should) : import pkg.mod1 : sym1, sym2, pkg.mod2 : sym1, sym2, pkg.mod3 : sym1; Can anyone see why this created attention?
If can you don't know the answer, it's because it "requires effort to understand".
Feb 22
prev sibling next sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
I still believe it should be something more readable:

import std.stdio, std.conv : [ to, from ], std.algorithm : doSomething,
std.whatever;

On Thu, Feb 22, 2018 at 11:30 AM, psychoticRabboit via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 On Thursday, 22 February 2018 at 09:42:47 UTC, Atila Neves wrote:

 I'm going to a) never write these imports and b) pretend this feature
 doesn't exist.

 Atila
what about something like this then? import std.stdio; std.conv: to, from; std.algorithm: doSomething; std.whatever; just one simple rule; multiple imports on a line are seperated with ; surely the parser or whatever it's called, could work with that clean and simple solution.
Feb 22
parent reply psychoticRabbit <meagain meagain.com> writes:
On Thursday, 22 February 2018 at 10:42:46 UTC, Daniel Kozak wrote:
 I still believe it should be something more readable:

 import std.stdio, std.conv : [ to, from ], std.algorithm : 
 doSomething, std.whatever;
yeah.. nice.. though we can make that even easier by dropping ":" i.e. import std.rabbit [food, water], std.house, std.family [carer];
Feb 22
parent reply Martin Nowak <code dawg.eu> writes:
On Thursday, 22 February 2018 at 11:15:35 UTC, psychoticRabbit 
wrote:
 import std.rabbit [food, water], std.house, std.family [carer];
What about the million lines of existing code using import std.stdio : writeln, writefln;
Feb 22
parent reply psychotyicRabbit <meagain meagain.com> writes:
On Friday, 23 February 2018 at 01:57:37 UTC, Martin Nowak wrote:
 On Thursday, 22 February 2018 at 11:15:35 UTC, psychoticRabbit 
 wrote:
 import std.rabbit [food, water], std.house, std.family [carer];
What about the million lines of existing code using import std.stdio : writeln, writefln;
I actually like selective importing like that. It tells me, the programmer was only interested in writeln and writefln from that module. It provides clarity of intention, as well as instructing new comers what modules contain, and where to find them. Selective importing is a great tool for new comers to become familiar with the library - and lets be honest - it's all about the libraries these days - so the more one knows about them, the better they'll be utilised. Also, D is pretty good a depracating stuff, so why not deprecate the current way of imports, and gradually move to something (that resolves issues): e.g. import std.stdio, std.whatever[this, that], std.somethingelse, std.grr[wtf]; I actually really like that syntax. It's really efficient for my brain to process.
Feb 22
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, February 23, 2018 02:20:41 psychotyicRabbit via Digitalmars-d-
announce wrote:
 Also, D is pretty good a depracating stuff, so why not deprecate
 the current way of imports, and gradually move to something (that
 resolves issues):

 e.g.

 import std.stdio, std.whatever[this, that], std.somethingelse,
 std.grr[wtf];

 I actually really like that syntax. It's really efficient for my
 brain to process.
We deprecate stuff when we need to, but every time we deprecate something, it breaks code (even if it's not immediate breakage), so the benefits that come from a deprecation need to be worth the breakage that it causes. Every D program on the planet which isn't completely trivial uses imports, and many of them use selective imports. So, you're talking about breaking a large percentage of the existing programs for a syntax change. That's not likely to go over well. Large breakage like that can be acceptable when it clearly fixes bugs but not just for aesthetics. - Jonathan M Davis
Feb 22
next sibling parent psychoticRabbit <meagain meagain.com> writes:
On Friday, 23 February 2018 at 02:31:34 UTC, Jonathan M Davis 
wrote:
 We deprecate stuff when we need to, but every time we deprecate 
 something, it breaks code (even if it's not immediate 
 breakage), so the benefits that come from a deprecation need to 
 be worth the breakage that it causes. Every D program on the 
 planet which isn't completely trivial uses imports, and many of 
 them use selective imports. So, you're talking about breaking a 
 large percentage of the existing programs for a syntax change. 
 That's not likely to go over well. Large breakage like that can 
 be acceptable when it clearly fixes bugs but not just for 
 aesthetics.

 - Jonathan M Davis
yeah I do agree. I'd prefer no change. I don't really see the need. On the otherhand, if change is coming, lets make it a sensible change ;-)
Feb 22
prev sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Friday, 23 February 2018 at 02:31:34 UTC, Jonathan M Davis 
wrote:
 We deprecate stuff when we need to, but every time we deprecate 
 something, it breaks code (even if it's not immediate 
 breakage), so the benefits that come from a deprecation need to 
 be worth the breakage that it causes. Every D program on the 
 planet which isn't completely trivial uses imports, and many of 
 them use selective imports. So, you're talking about breaking a 
 large percentage of the existing programs for a syntax change. 
 That's not likely to go over well. Large breakage like that can 
 be acceptable when it clearly fixes bugs but not just for 
 aesthetics.

 - Jonathan M Davis
oh..and really, there should be no need to deprecate anything here anyway. surely D can handle the current way of doing imports (not including that rubbish in beta), and also a new way for those that want to use it, or those that want put stuff on a single line. import std.stdio, std.whatever[this, that], std.somethingelse, std.grr[wtf]; This new syntax that I'm proposing (after reviewing discussions here) seems like a sensible change. It's very easy for the brain to chunk into components (unlike that rubbish in beta), and it introduces thinking about 'selective imports' as just being an array of selections, using the same array like syntax used elsewhere in D. I would be interested to see what controversy would result from this new proposal, compared to the current change in beta.
Feb 22
parent reply Seb <seb wilzba.ch> writes:
On Friday, 23 February 2018 at 03:20:22 UTC, psychoticRabbit 
wrote:
 compared to the current change in beta.
FWIW the change is almost gone from the beta: https://github.com/dlang/dmd/pull/7939
Feb 22
next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Friday, 23 February 2018 at 03:26:11 UTC, Seb wrote:
 On Friday, 23 February 2018 at 03:20:22 UTC, psychoticRabbit 
 wrote:
 compared to the current change in beta.
FWIW the change is almost gone from the beta: https://github.com/dlang/dmd/pull/7939
I'm glad common sense seems to be winning ;-) This is a good case for 'review of process' I think. The original request for change was very flawed, in that it presupposed "importing as an expenditure that should be minimized.". I think that is highly debatable, and more people should have had the opportunity to comment on that. Second, none of the proposed syntax options was sufficiently clear, for the brain to chunk into its components. This is a serious issue and should be of greatest priority when introducing changes to syntax (no matter how small the change). Changes to syntax need to be tested widely, for precisely this reason. You can do whole Phd's on this topic. Third, making D more and more like a quick scripting/hacking language (by removing or hiding so called 'noise', is not a good idea in my opinion. That too seemed to be a motivator for at some aspect of the change.
Feb 22
parent reply Norm <norm.rowtree gmail.com> writes:
[snip]
On Friday, 23 February 2018 at 04:06:23 UTC, psychoticRabbit 
wrote:
 Third, making D more and more like a quick scripting/hacking 
 language (by removing or hiding so called 'noise', is not a 
 good idea in my opinion. That too seemed to be a motivator for 
 at some aspect of the change.
This import feature and surrounding discussion I couldn't care less about but I have to chime in and disagree with this particular point. Ability to quickly script in D was a big selling point for D at my workplace, I'd say *the* feature that got uninterested developers listening and trying the language. Being able to replace their Python scripts with a fast native language that is also used for application and drivers development was a winning formula. Cheers, Norm
Feb 23
next sibling parent Martin Nowak <code dawg.eu> writes:
On Friday, 23 February 2018 at 09:48:33 UTC, Norm wrote:
 Ability to quickly script in D was a big selling point for D at 
 my workplace, I'd say *the* feature that got uninterested 
 developers listening and trying the language. Being able to 
 replace their Python scripts with a fast native language that 
 is also used for application and drivers development was a 
 winning formula.
Yes, it's regularly mentioned, and indeed D makes a nice Python rival in some use-cases like scientific computing. Usually you don't need a fast native language for scripts though, but having to only learn a single language ecosystem can still be helpful.
Feb 23
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, February 23, 2018 09:48:33 Norm via Digitalmars-d-announce wrote:
 [snip]
 On Friday, 23 February 2018 at 04:06:23 UTC, psychoticRabbit

 wrote:
 Third, making D more and more like a quick scripting/hacking
 language (by removing or hiding so called 'noise', is not a
 good idea in my opinion. That too seemed to be a motivator for
 at some aspect of the change.
This import feature and surrounding discussion I couldn't care less about but I have to chime in and disagree with this particular point. Ability to quickly script in D was a big selling point for D at my workplace, I'd say *the* feature that got uninterested developers listening and trying the language. Being able to replace their Python scripts with a fast native language that is also used for application and drivers development was a winning formula.
I don't know that scripts are really all that big a deal, since being able to slap #/usr/bin/env rdmd at the top really just saves you from having to compile the binary yourself, but I do use that functionality from time to time, and regardless of whether that functionality is supported, being able to write small programs to do stuff is invaluable. I do frequently use shell scripts when stuff is simple, but it doesn't take much before it's just easier to write them in D, and on Windows, I sure don't want to be writing batch scripts. So, being able to reasonably write small D programs to perform simple tasks is huge. And regardless of the scripting support, D itself makes that _way_ nicer than C/C++ does. Writing programs that are hundreds of thousands or millions of lines long is definitely not D's only use case. - Jonathan M Davis
Feb 23
prev sibling next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Friday, 23 February 2018 at 09:48:33 UTC, Norm wrote:
 This import feature and surrounding discussion I couldn't care 
 less about ...
I actually spend far more time reading large chunks of code, than writing code, and I certainly do NOT want to spend extra time deciphering imports, due to an unpopular and confusing syntax change. If I were mainly writing 'scripts', then I too would probably not care less ;-) If D just wants to become a compiled scripting language...good luck to it. I'll go find a proper progamming langauge long before that happens.
Feb 23
next sibling parent reply Martin Nowak <code dawg.eu> writes:
On Friday, 23 February 2018 at 10:48:10 UTC, psychoticRabbit 
wrote:
 If D just wants to become a compiled scripting language...good 
 luck to it.
That's certainly not the goal, but as with every tool people become very familiar with, it's used creatively for things other than initially intended.
Feb 23
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, February 23, 2018 10:57:21 Martin Nowak via Digitalmars-d-
announce wrote:
 On Friday, 23 February 2018 at 10:48:10 UTC, psychoticRabbit

 wrote:
 If D just wants to become a compiled scripting language...good
 luck to it.
That's certainly not the goal, but as with every tool people become very familiar with, it's used creatively for things other than initially intended.
And D has a lot of the easy-of-use that folks like to attribute to scripting languages. Thanks to how hard stuff like string processing is in C/C++, there's frequently a perception that compiled languages are hard to use for a lot of stuff that folks like to use scripting languages for, whereas that really has nothing to do with whether the language is compiled or not. And D is much more on-par with scripting languages in that regard even though it's compiled. So, if someone uses a scripting language because of its use-of-use, D frequently works for those use cases just as well. There's no requirement that a compiled language be used for large programs or that it be hard to use for simple tasks. And D can be used for a whole range of program sizes and tasks. It's a solid general purpose language, and small scripts fit into that just as well as large applications do. - Jonathan M Davis
Feb 23
parent aberba <karabutaworld gmail.com> writes:
On Friday, 23 February 2018 at 11:24:24 UTC, Jonathan M Davis 
wrote:
 On Friday, February 23, 2018 10:57:21 Martin Nowak via 
 Digitalmars-d- announce wrote:
 On Friday, 23 February 2018 at 10:48:10 UTC, psychoticRabbit

 wrote:
 If D just wants to become a compiled scripting 
 language...good luck to it.
That's certainly not the goal, but as with every tool people become very familiar with, it's used creatively for things other than initially intended.
And D has a lot of the easy-of-use that folks like to attribute to scripting languages. Thanks to how hard stuff like string processing is in C/C++, there's frequently a perception that compiled languages are hard to use for a lot of stuff that folks like to use scripting languages for, whereas that really has nothing to do with whether the language is compiled or not. And D is much more on-par with scripting languages in that regard even though it's compiled. So, if someone uses a scripting language because of its use-of-use, D frequently works for those use cases just as well. There's no requirement that a compiled language be used for large programs or that it be hard to use for simple tasks. And D can be used for a whole range of program sizes and tasks. It's a solid general purpose language, and small scripts fit into that just as well as large applications do. - Jonathan M Davis
Very well said. Coming from the world of full stack (front-end and back-end), D is the only language that provides me with all of C/C++ but in a more Javascript & php way of easing development. Not only strings that are convenient to work with in D, but its has generally been for me... convenience in dealing with data generally. D is very well designed, easy to understand, and can be a beast if you want. Its one language you need to learn to be useful in every domain. D is already enough as a scripting language. I can code in D as fast as in Javascript (Nodejs). That's why my complaints have not been about the language but packages/library availability. D is my answer to one language for everything. Being general purpose language at it's core is a good thing. Best of both worlds. std.range, std.algorithms, std. string, std.datetime solves 60% of all my needs. Useful stuff on Dub too. More will come with time.
Feb 23
prev sibling parent reply Norm <norm.rowtree gmail.com> writes:
On Friday, 23 February 2018 at 10:48:10 UTC, psychoticRabbit 
wrote:
 On Friday, 23 February 2018 at 09:48:33 UTC, Norm wrote:
 This import feature and surrounding discussion I couldn't care 
 less about ...
I actually spend far more time reading large chunks of code, than writing code, and I certainly do NOT want to spend extra time deciphering imports, due to an unpopular and confusing syntax change. If I were mainly writing 'scripts', then I too would probably not care less ;-) If D just wants to become a compiled scripting language...good luck to it. I'll go find a proper progamming langauge long before that happens.
Well, D is already a compiled scripting language :) It is also a language used for BSD and Linux kernel drivers, applications, backend servers et. al. So you can have your cake and eat it too. Cheers, Norm
Feb 23
parent psychoticRabbit <meagain meagain.com> writes:
On Friday, 23 February 2018 at 23:46:02 UTC, Norm wrote:
 Well, D is already a compiled scripting language :)
technically (and otherwise) that is not correct...thank god! lets keep it that way.
Feb 23
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 23 February 2018 at 09:48:33 UTC, Norm wrote:
 [snip]
 On Friday, 23 February 2018 at 04:06:23 UTC, psychoticRabbit 
 wrote:
 Third, making D more and more like a quick scripting/hacking 
 language (by removing or hiding so called 'noise', is not a 
 good idea in my opinion. That too seemed to be a motivator for 
 at some aspect of the change.
This import feature and surrounding discussion I couldn't care less about but I have to chime in and disagree with this particular point. Ability to quickly script in D was a big selling point for D at my workplace, I'd say *the* feature that got uninterested developers listening and trying the language. Being able to replace their Python scripts with a fast native language that is also used for application and drivers development was a winning formula.
Absolutely. D scripting is the trojan horse that enables introduction of it in hostile environment. Runnable compiled source code is nice.
Feb 23
parent reply psychoticRabbit <meagain meagain.com> writes:
On Friday, 23 February 2018 at 12:06:23 UTC, Patrick Schluter 
wrote:
 Absolutely. D scripting is the trojan horse that enables 
 introduction of it in hostile environment. Runnable compiled 
 source code is nice.
scripting languages is reinventing computer science.. only really badly.
Feb 23
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 23 February 2018 at 13:42:45 UTC, psychoticRabbit 
wrote:
 On Friday, 23 February 2018 at 12:06:23 UTC, Patrick Schluter 
 wrote:
 Absolutely. D scripting is the trojan horse that enables 
 introduction of it in hostile environment. Runnable compiled 
 source code is nice.
scripting languages is reinventing computer science.. only really badly.
No, scripting languages is about getting shit done...
Feb 23
parent psychoticRabbit <meagain meagain.com> writes:
On Friday, 23 February 2018 at 18:13:51 UTC, Patrick Schluter 
wrote:
 On Friday, 23 February 2018 at 13:42:45 UTC, psychoticRabbit 
 wrote:
 On Friday, 23 February 2018 at 12:06:23 UTC, Patrick Schluter 
 wrote:
 Absolutely. D scripting is the trojan horse that enables 
 introduction of it in hostile environment. Runnable compiled 
 source code is nice.
scripting languages is reinventing computer science.. only really badly.
No, scripting languages is about getting shit done...
that's exactly the problem. we're all to focused on getting 'shit' done ;-)
Feb 23
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Friday, 23 February 2018 at 03:26:11 UTC, Seb wrote:
 On Friday, 23 February 2018 at 03:20:22 UTC, psychoticRabbit 
 wrote:
 compared to the current change in beta.
FWIW the change is almost gone from the beta: https://github.com/dlang/dmd/pull/7939
Glad its *almost* gone. That change *almost* freaked me out.
Feb 23
prev sibling parent reply =?UTF-8?B?QXVyw6lsaWVu?= Plazzotta <myemail youknow.com> writes:
On Friday, 23 February 2018 at 02:20:41 UTC, psychotyicRabbit 
wrote:
 On Friday, 23 February 2018 at 01:57:37 UTC, Martin Nowak wrote:
 On Thursday, 22 February 2018 at 11:15:35 UTC, psychoticRabbit 
 wrote:
 import std.rabbit [food, water], std.house, std.family 
 [carer];
 Also, D is pretty good a depracating stuff, so why not 
 deprecate the current way of imports, and gradually move to 
 something (that resolves issues):

 import std.stdio, std.whatever[this, that], std.somethingelse, 
 std.grr[wtf];
Perhaps, we could use Backus-Naur notation, as it is already widely known into formal documents all over the globe, like the following: import std.stdio, std.whatever{this, that}, std.somethingelse, std.grr{wtf}; That is with curly brackets instead of square brackets like you suggest :)
Feb 23
parent reply psychoticRabbit <meagain meagain.com> writes:
On Friday, 23 February 2018 at 16:03:56 UTC, Aurélien Plazzotta 
wrote:
 Perhaps, we could use Backus-Naur notation, as it is already 
 widely known into formal documents all over the globe, like the 
 following:

 import std.stdio, std.whatever{this, that}, std.somethingelse, 
 std.grr{wtf};

 That is with curly brackets instead of square brackets like you 
 suggest :)
Yeah...again.. I'd prefer to not to have to think differently about syntax, just for writing imports. That's why I'd prefer to just think of them as arrays using D's array like syntax. import std.stdio [writeln, write = cwrite, writefln], std.whatever; I'm not sufficiently motivated to do anything here anyway, as I don't believe a case for change can really be justified - cause how many imports can you realistically include on a single line anyway? The current way is just fine, and provides really good clarity for what's going on. But I would (and am) very, very motivated to oppose introduction of an obscure, confusing, or foreign syntax. The real motivator for the change, as i see it, seemed to be related to thinking that the imports section was not really for human consumption - which it not true at all. The second motivate seemed to be related to saving a few keystrokes or line space. Again, human consumption should take priority here in my view. Anyway, the point is moot at this point - since the change is being reversed and nobody seems motivated to push it again. Which is just fine with me ;-)
Feb 23
parent reply zabruk70 <sorry noem.ail> writes:
i don't understand whole theread.
why all import must be written on one line?
curent syntax very handy and readable.
Feb 23
parent psychoticRabbit <meagain meagain.com> writes:
On Saturday, 24 February 2018 at 07:09:05 UTC, zabruk70 wrote:
 i don't understand whole theread.
 why all import must be written on one line?
 curent syntax very handy and readable.
you must have understood the thread, cause you summarised it pretty well ;-)
Feb 23
prev sibling parent David Gileadi <gileadisNOSPM gmail.com> writes:
On 2/22/18 3:30 AM, psychoticRabboit wrote:
 On Thursday, 22 February 2018 at 09:42:47 UTC, Atila Neves wrote:
 I'm going to a) never write these imports and b) pretend this feature 
 doesn't exist.

 Atila
what about something like this then? import std.stdio; std.conv: to, from; std.algorithm: doSomething; std.whatever; just one simple rule; multiple imports on a line are seperated with ; surely the parser or whatever it's called, could work with that clean and simple solution.
Using a semicolon occurred to me too. If the feature is to be kept, this is the syntax that is easiest to read and remember for me.
Feb 22
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak wrote:
 On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
 17. Allow multiple selective imports from different modules in 
 a single import statement

 I have a bad feeling that that one is going to be a source of 
 a raft of bugs for years to come.
No need to use it if you don't like it.
I don't think I will.
 It's particularly useful for small examples, localized imports 
 and hacking.
Eh, the problem is it won't be used just for that.
 It's mainly a generalisation of the existing possibility to mix 
 module imports and one selective import at the end.
Yes, I recognize the need for something like that, as I too have been annoyed that I had to split up import lines when adding selective symbols.
 If you prefer java-like 50 lines import manifests, then by all 
 means keep using those.
I don't, but there's a clarity to those that's not there with this.
 How would that feature cause bugs though?
Two ways I can think of, first, local imports was supposed to be a small change and yet here we are fixing symbol leaks with it _years_ later. Looking at your patch now, it's so small that maybe it won't have those problems. The other are the ambiguity and readability issues that others have already mentioned, that will trip up D devs for years to come. I thought about chiming in on that PR when it was open, but didn't because the vote was split at 5-5 and I thought it wouldn't get merged. Also, I'm not against the idea in principle, but I do wish you'd chosen better syntax, such as not reusing the comma to split modules too. I don't have a better separator suggestion though, `|`?
Feb 21
parent psychoticRabbit <meagain meagain.com> writes:
On Wednesday, 21 February 2018 at 15:33:02 UTC, Joakim wrote:
 I thought about chiming in on that PR when it was open, but 
 didn't because the vote was split at 5-5 and I thought it 
 wouldn't get merged.  Also, I'm not against the idea in 
 principle, but I do wish you'd chosen better syntax, such as 
 not reusing the comma to split modules too.  I don't have a 
 better separator suggestion though, `|`?
How about the plain obvious? import std.stdio:write,writeln,writefln & std.array:join,split,replicate;
Feb 21
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak wrote:
Regarding the sheer amount of discussion I want to note that this 
was primarily seen as a regularization of the existing grammar.

import mod1, mod2 : sym1, sym2;

Certainly other languages have decided on a clearer syntax for 
selective imports, but that's what was chosen for D a long time 
ago.
Learning D you'll find that the selective import syntax is 
ambiguous in your first week, so I've stopped being annoyed by 
that some 5 years ago.

The main use-case for craming multiple imports into a line is not 
libraries but scripting, examples, and maybe unit tests.
And indeed the changelog entry could have been a bit clearer and 
easier to grasp.

----

Unfortunately it's a bit hard to find arguments in the discussion 
below, would have been cool if there were a few well argumented 
comments instead dozens of +1s.

- this grammar is ambiguous

   It has always been in various ways and that's annoying to learn 
when you first deal with D. Personally I find it even more 
annoying that you can mix imports and selective imports, but only 
in a very specific exception.

- why not X instead

   Go for it and try to find a consensus. I don't think the issue 
is big enough to warrant a huge design and bikeshedding 
discussion.

- each imported module should be on it's own line

   That's your opinion, my opinion is that importing 6 symbols 
from 6 different modules for a tiny cli tool sucks and bloats 
code example. So the alternative is to not use selective imports, 
but only those and static imports have a clear path to become 
lazy (https://issues.dlang.org/show_bug.cgi?id=13255).
   For projects and libraries it hardly matters, just adopt to the 
style-guide and existing code.
   Apparently I didn't use it a single time here 
https://github.com/MartinNowak/io, but all the time here 
https://github.com/MartinNowak/AoC17.
   Cannot say that it even took an active decision. It's just a 
very different mode if you want to quickly script sth. or if you 
set aside time to write a well-documented library.

- use std.experimental.scripting

   Indeed an alternative with a similar goal, reducing the amount 
of typing/noise for hacking. Importing all phobos modules will 
lead to a couple of symbol conflicts (e.g. write), and it still 
increases compile times and binary sizes noteably (though compile 
time is a lot better than it used to be).
   Not sure that this approach will pan out in the long-term, but 
a well curated package of the most used functions would indeed be 
helpful as of today.

- why hasn't this been a DIP

   Because it looked primarily like a minor grammar rectification 
that doesn't break anything and is entirely optional.
   Also DIPs are a crucial process for our language, and it seems 
problematic to clog it with trivialities.

----

On the other side please note that:

- you don't have to use it
- it will unlikely land in phobos' style-guide
- it's useful for talks, posts, code puzzles or on a repl where 
code is size constrained
- there is no ambiguity or chance for bugs
- practical examples of this usage are hardly confusing

   import std.stdio : writeln, std.algorithm : find;

- what's usually of relevance is the call-site not what you import
- there is syntax highlighting
- we're currently proliferating selective imports which cause a 
lot of D code to become very brittle
   
(https://github.com/andralex/phobos/blob/cd3152c7bf4466e74b7fb9bd43d47e996caf5918/std/datetime/systime.d#L10076-L10083)
- remember that some people use `import mod1, mod2, mod3, mod4;` 
at least sometimes while others
   prefer each import on it's own line
- imports are mostly for tooling, less for humans
   - many java editors collapse the import manifest at the top
   - a lot of languages have an import std.* operator or 
auto-imports
   - you might want to automate import declarations at some point

And last but not least, the simpler the topic the more opinions, 
so please refrain from "I don't like it, +1" and leave space for 
actual arguments.

-Martin
Feb 22
next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote:
 Unfortunately it's a bit hard to find arguments in the 
 discussion below, would have been cool if there were a few well 
 argumented comments instead dozens of +1s.
Go back and read all of this thread, properly.
 - this grammar is ambiguous
Isn't that an argument?
   It has always been in various ways and that's annoying to 
 learn when you first deal with D. Personally I find it even 
 more annoying that you can mix imports and selective imports, 
 but only in a very specific exception.

 - why not X instead
Aren't alternative ideas welcome?
   Go for it and try to find a consensus. I don't think the 
 issue is big enough to warrant a huge design and bikeshedding 
 discussion.
Some don't agree with you.
   That's your opinion, my opinion is that importing 6 symbols 
 from 6 different modules for a tiny cli tool sucks and bloats 
 code example.
That's your opinion.
   Indeed an alternative with a similar goal, reducing the 
 amount of typing/noise for hacking.
You seem overly eager to save some typing, and the expense of comprehension. I don't get it. That's what bring programming languages into disrepute.
 - why hasn't this been a DIP

   Because it looked primarily like a minor grammar 
 rectification that doesn't break anything and is entirely 
 optional.
Go back are read the 'arguments' are but 'optional' aspect.
   Also DIPs are a crucial process for our language, and it 
 seems problematic to clog it with trivialities.
This doesn't seem that trivial based on the discussion.
 ----

 On the other side please note that:

 - you don't have to use it
 - it will unlikely land in phobos' style-guide
 - it's useful for talks, posts, code puzzles or on a repl where 
 code is size constrained
 - there is no ambiguity or chance for bugs
 - practical examples of this usage are hardly confusing

   import std.stdio : writeln, std.algorithm : find;
Seriously? You came up with the simplest example to demonstrate you're argument?
 - remember that some people use `import mod1, mod2, mod3, 
 mod4;` at least sometimes while others
   prefer each import on it's own line
 - imports are mostly for tooling, less for humans
That's your opinion. I happen to think that imports help people discover where stuff resides. I've learnt a lot from looking at imports used.
   - many java editors collapse the import manifest at the top
   - a lot of languages have an import std.* operator or 
 auto-imports
That's why nobody know where anything is in the their library.
 And last but not least, the simpler the topic the more 
 opinions, so please refrain from "I don't like it, +1" and 
 leave space for actual arguments.
Again, go back and read this thread properly, and don't be so dismissive of the concerns people have expressed.
Feb 22
parent reply Martin Nowak <code dawg.eu> writes:
On Friday, 23 February 2018 at 00:41:58 UTC, psychoticRabbit 
wrote:
 On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote:
 Isn't that an argument?
Of course it is :). I tried to list the arguments I found in the thread and replied to them, trying to lead a proper discussion.
 - why not X instead
Aren't alternative ideas welcome?
Yes they are. There was quite some chances to bring them up, maybe this needs more room for comments.
   Go for it and try to find a consensus. I don't think the 
 issue is big enough to warrant a huge design and bikeshedding 
 discussion.
Some don't agree with you.
The price of discussing syntax, introducing an alternative (e.g. `import std.algorithm : { find, findSplit }`, and rewriting most D code is quite high.
 That's your opinion.
Yes, and it's an opinion that isn't reflected in the thread.
 You seem overly eager to save some typing, and the expense of 
 comprehension.
 I don't get it. That's what bring programming languages into 
 disrepute.
Reread what I wrote, you'll find that I make a distinction between scripting/hacking and programming.
 This doesn't seem that trivial based on the discussion.
It said seemed, so it might have been a wrong assessment. But I still think we have quite heavy topics on our plate, nogc, safe, phobos quality, dub infrastructure and this still seems like a very tiny change to me. Also https://en.wikipedia.org/wiki/Law_of_triviality, because this is certainly easier to grasp than https://github.com/dlang/druntime/pull/1282 (https://forum.dlang.org/post/mjsma6$196h$1 digitalmars.com) for which getting feedback is extremely tedious.
 I've learnt a lot from looking at imports used.
Interesting, you have a good example?
Feb 22
next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Friday, 23 February 2018 at 01:02:59 UTC, Martin Nowak wrote:
 Interesting, you have a good example?
yeah..phobos. I learn most about the various phobos libraries, and their usefulness, from looking at the various imports that phobos modules use. If they just used import *; I'd have no idea what was going on.
Feb 22
parent psychoticRabbit <meagain meagain.com> writes:
On Friday, 23 February 2018 at 01:17:26 UTC, psychoticRabbit 
wrote:
 On Friday, 23 February 2018 at 01:02:59 UTC, Martin Nowak wrote:
 Interesting, you have a good example?
yeah..phobos. I learn most about the various phobos libraries, and their usefulness, from looking at the various imports that phobos modules use. If they just used import *; I'd have no idea what was going on.
and worse, if phobos used this new so-called 'optional' syntax...then I'd probably have switched to another language by now. import pkg.mod1 : sym1, sym2, pkg.mod2 : sym1, sym2, pkg.mod3 : sym1; I don't have the patience to decipher stuff like that.
Feb 22
prev sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 23 February 2018 at 01:02:59 UTC, Martin Nowak wrote:
 Also https://en.wikipedia.org/wiki/Law_of_triviality, because 
 this is certainly easier to grasp than 
 https://github.com/dlang/druntime/pull/1282 
 (https://forum.dlang.org/post/mjsma6$196h$1 digitalmars.com)
If nobody opposes, commit it to experimental. What an AA can have beside getter and setter?
Feb 23
parent Kagamin <spam here.lot> writes:
 https://github.com/dlang/druntime/pull/1282
github shows me just two changes in makefiles and nothing else, need to find where the code comes from.
Feb 23
prev sibling next sibling parent Martin Nowak <code dawg.eu> writes:
On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote:
 On the other side please note that:
Forgot one important point: - practially unqualified modules are extremely rare, so the tiny ambiguous grammar case is hardly relevant.
Feb 22
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, February 23, 2018 00:05:59 Martin Nowak via Digitalmars-d-
announce wrote:
 The main use-case for craming multiple imports into a line is not
 libraries but scripting, examples, and maybe unit tests.
 And indeed the changelog entry could have been a bit clearer and
 easier to grasp.
In that case, I would expect the programmer to just forgo selective imports. If they care that much about making the code short and/or writing the code quickly, then that makes a lot more sense than trying to cram as many selective imports as possible on a single line - particularly when the syntax for that is hard to read.
    Go for it and try to find a consensus. I don't think the issue
 is big enough to warrant a huge design and bikeshedding
 discussion.
I can sympathize with wanting to avoid bikeshedding, but almost no one who has posted thinks that this is a good idea. Pretty much no one likes the syntax, and they either want a different syntax or don't want the feature at all. As such, it seems like a bad idea to add it. Not having total consensus is one thing. Having almost total consensus that it's a bad idea is another entirely.
 On the other side please note that:

 - you don't have to use it
This is always, always, always a terrible argument, because as much as you may not have to use a feature, you have to deal with code that other people write where they used the feature. And the syntax of this feature is hard to read, making it particularly bad when you encounter it if you never use it, since then you're that much less likely to be able to read it well. - Jonathan M Davis
Feb 22
parent reply Martin Nowak <code dawg.eu> writes:
On Friday, 23 February 2018 at 01:16:24 UTC, Jonathan M Davis 
wrote:
 I can sympathize with wanting to avoid bikeshedding, but almost 
 no one who has posted thinks that this is a good idea.
This was meant for the discussion of a new syntax for selective imports like `import mod : { sym1, sym2 }` which seems like too much churn to be worthwhile.
Feb 22
parent psychoticRabbit <meagain meagain.com> writes:
On Friday, 23 February 2018 at 01:53:45 UTC, Martin Nowak wrote:
 On Friday, 23 February 2018 at 01:16:24 UTC, Jonathan M Davis 
 wrote:
 I can sympathize with wanting to avoid bikeshedding, but 
 almost no one who has posted thinks that this is a good idea.
This was meant for the discussion of a new syntax for selective imports like `import mod : { sym1, sym2 }` which seems like too much churn to be worthwhile.
import mod : { sym1, sym2 } thats not nice syntax - for these reasons: first, why is the : needed? {} is enough to enscapsulate the intention. second, why are using {} instead of [] [] would allow me to think of selective importing, as though I were importing an array of selections. e.g: import std.stdio, std.whatever[this, that], std.somethingelse, std.grr[wtf]; so using [] would be consistent with using array like syntax elsewhere in D, and would require no additional effort to think about.
Feb 22
prev sibling next sibling parent reply Rubn <where is.this> writes:
On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote:
 - each imported module should be on it's own line

   That's your opinion, my opinion is that importing 6 symbols 
 from 6 different modules for a tiny cli tool sucks and bloats 
 code example. So the alternative is to not use selective 
 imports, but only those and static imports have a clear path to 
 become lazy (https://issues.dlang.org/show_bug.cgi?id=13255).
This can be solved by adding a package.d to phobos. This doesn't need a language change that introduces more ambiguities for such a subjective matter as "I'm too lazy to write 5 more lines of code". 5 Lines of code is hardly bloat for a code example. Example code is better to follow best practices, or you get the whole `using namespace std` situation like you do with C++. The people that actually can comprehend won't be hindered by it, and everyone else it won't make a difference cause they have no understanding of what they are doing and just copy and paste the code.
Feb 22
parent Seb <seb wilzba.ch> writes:
On Friday, 23 February 2018 at 01:34:54 UTC, Rubn wrote:
 On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote:
 - each imported module should be on it's own line

   That's your opinion, my opinion is that importing 6 symbols 
 from 6 different modules for a tiny cli tool sucks and bloats 
 code example. So the alternative is to not use selective 
 imports, but only those and static imports have a clear path 
 to become lazy 
 (https://issues.dlang.org/show_bug.cgi?id=13255).
This can be solved by adding a package.d to phobos. This doesn't need a language change that introduces more ambiguities for such a subjective matter as "I'm too lazy to write 5 more lines of code". 5 Lines of code is hardly bloat for a code example. Example code is better to follow best practices, or you get the whole `using namespace std` situation like you do with C++. The people that actually can comprehend won't be hindered by it, and everyone else it won't make a difference cause they have no understanding of what they are doing and just copy and paste the code.
Yes, with 2.079 those who want, can do `import std.experimental.all` [1]. (It has been renamed from scripting to all since the prerelease changelog was created) In later versions, it might be renamed to std/package.d, but we first want to assess whether there are potential problems except the potential collisions and potential decrease in "understandability". Anyhow, `experimental` is a good playground for such tests. [1] https://dlang.org/changelog/2.079.0.html#std-experimental-scripting
Feb 22
prev sibling next sibling parent Joakim <dlang joakim.fea.st> writes:
On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote:
 - practical examples of this usage are hardly confusing

   import std.stdio : writeln, std.algorithm : find;
I agree that that's not so bad, though it's more likely to look like this: import std.stdio : writeln, stdin, stderr, stdout, std.algorithm : find, splitter, strip, std.string: chomp, splitLines; Do you not see that people don't want to parse that in their head? Here's what it looks like when some joker has a bunch of modules all in the same top-level folder: import game : write, call, mean, engine : render, debug, blit, sprite : display, hide, move; People don't want to read and figure out imports like that. As I've said repeatedly, I like the feature and the problem it's trying to solve, just please give us some better syntax to make it easier to read.
 - we're currently proliferating selective imports which cause a 
 lot of D code to become very brittle
   
 (https://github.com/andralex/phobos/blob/cd3152c7bf4466e74b7fb9bd43d47e996caf5918/std/datetime/systime.d#L10076-L10083)
I don't know what's "brittle" about that, perhaps too verbose for your liking, but certainly clear.
 And last but not least, the simpler the topic the more 
 opinions, so please refrain from "I don't like it, +1" and 
 leave space for actual arguments.
While you and Walter are right that it's easy to bikeshed this relatively simple topic, please also consider that imports are something that people use all the time. Every time I have to write some trivial test executable, I have to write some imports first, which can be as long or longer than writing the simple executed code itself. This means every D dev has written some imports and doesn't want to seem them getting less clear to parse. Maybe this is saliency bias, but it is worth weighing when changing a commonly-used feature: https://thedecisionlab.com/bias/salience-bias/
Feb 22
prev sibling parent Kagamin <spam here.lot> writes:
On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote:
 The main use-case for craming multiple imports into a line is 
 not libraries but scripting, examples, and maybe unit tests.
Those are cases when selective imports shouldn't be used. experimental.scripting was introduced to reduce import length to absolute minimum - 11 characters.
   That's your opinion, my opinion is that importing 6 symbols 
 from 6 different modules for a tiny cli tool sucks and bloats 
 code example. So the alternative is to not use selective 
 imports, but only those and static imports have a clear path to 
 become lazy (https://issues.dlang.org/show_bug.cgi?id=13255).
Are renamed imports already lazy? Tiny cli tool uses all its imports and doesn't benefit from laziness, only libraries do.
 - use std.experimental.scripting

   Indeed an alternative with a similar goal, reducing the 
 amount of typing/noise for hacking. Importing all phobos 
 modules will lead to a couple of symbol conflicts (e.g. write),
It's perfectly thinkable to use both `write` functions, and selective imports won't help you there, but renamed imports will. Is it just me or people ignore existence of renamed imports? #RenamedImportsMatter
 and it still increases compile times and binary sizes noteably 
 (though compile time is a lot better than it used to be).
Is it because of dead templates? As a temporary solution you can compile the code to a library, this way the linker will be able to skip unreferenced code.
 - why hasn't this been a DIP

   Because it looked primarily like a minor grammar 
 rectification that doesn't break anything and is entirely 
 optional.
   Also DIPs are a crucial process for our language, and it 
 seems problematic to clog it with trivialities.
Though the feature met skepticism from the start. Maybe voting can be used as a simplified DIP process, just needs more people.
 - it's useful for talks, posts, code puzzles or on a repl where 
 code is size constrained
Non-selective always win in terms of size.
 - we're currently proliferating selective imports which cause a 
 lot of D code to become very brittle
   
 (https://github.com/andralex/phobos/blob/cd3152c7bf4466e74b7fb9bd43d47e996caf5918/std/datetime/systime.d#L10076-L10083)
I'd convert those to non-selective imports. import std.algorithm.iteration, std.ascii, std.exception, std.format, std.meta, std.range, std.stdio, std.string; (well, my editor has decent word wrapping)
Feb 23
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak wrote:
 On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
 17. Allow multiple selective imports from different modules in 
 a single import statement

 I have a bad feeling that that one is going to be a source of 
 a raft of bugs for years to come.
No need to use it if you don't like it. It's particularly useful for small examples, localized imports and hacking. It's mainly a generalisation of the existing possibility to mix module imports and one selective import at the end. If you prefer java-like 50 lines import manifests, then by all means keep using those. How would that feature cause bugs though?
AFAICT Rust now has introduced the exactly same feature. It's quite interesting to see that there was no outcry by the community and it was universally liked: https://blog.rust-lang.org/2018/03/29/Rust-1.25.html https://github.com/rust-lang/rust/issues/44494
Mar 30
next sibling parent meppl <mephisto nordhoff-online.de> writes:
On Saturday, 31 March 2018 at 00:25:47 UTC, Seb wrote:
 On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak 
 wrote:
 On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
 [...]
No need to use it if you don't like it. It's particularly useful for small examples, localized imports and hacking. It's mainly a generalisation of the existing possibility to mix module imports and one selective import at the end. If you prefer java-like 50 lines import manifests, then by all means keep using those. How would that feature cause bugs though?
AFAICT Rust now has introduced the exactly same feature. It's quite interesting to see that there was no outcry by the community and it was universally liked: https://blog.rust-lang.org/2018/03/29/Rust-1.25.html https://github.com/rust-lang/rust/issues/44494
the curly brackets make the rust implementation more readable. The dmd implementation didn't use brackets. I believe that's a main reason for the resistance from the people
Mar 30
prev sibling next sibling parent Joakim <dlang joakim.fea.st> writes:
On Saturday, 31 March 2018 at 00:25:47 UTC, Seb wrote:
 On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak 
 wrote:
 On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
 17. Allow multiple selective imports from different modules 
 in a single import statement

 I have a bad feeling that that one is going to be a source of 
 a raft of bugs for years to come.
No need to use it if you don't like it. It's particularly useful for small examples, localized imports and hacking. It's mainly a generalisation of the existing possibility to mix module imports and one selective import at the end. If you prefer java-like 50 lines import manifests, then by all means keep using those. How would that feature cause bugs though?
AFAICT Rust now has introduced the exactly same feature. It's quite interesting to see that there was no outcry by the community and it was universally liked: https://blog.rust-lang.org/2018/03/29/Rust-1.25.html https://github.com/rust-lang/rust/issues/44494
As meppl says, they require braces, which the D version didn't, so not "exactly same." Besides look at that horrid syntax even before this addition, drowning in colons, they seem to carry over some of the worst punctuation style from C++. About the only good thing I can say about it is that 'use' is a better, shorter keyword than 'import.'
Mar 31
prev sibling parent Kagamin <spam here.lot> writes:
On Saturday, 31 March 2018 at 00:25:47 UTC, Seb wrote:
 AFAICT Rust now has introduced the exactly same feature. It's 
 quite interesting to see that there was no outcry by the 
 community and it was universally liked:

 https://blog.rust-lang.org/2018/03/29/Rust-1.25.html
 https://github.com/rust-lang/rust/issues/44494
use std::sync::{Arc, atomic::{AtomicBool, Ordering}}; Well, sifting through such imports is tame compared to what they have to do, so they will barely notice it :) rust is tinkering-oriented after all.
Mar 31
prev sibling next sibling parent Radu <void null.pt> writes:
On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
 On Monday, 19 February 2018 at 15:45:30 UTC, bachmeier wrote:
 On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak 
 wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to 
 the 77 contributors for this release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.079.0.html

 As usual please report any bugs at https://issues.dlang.org

 - ----

 This is probably the most feature-laden 2 month release ever.
 ...
This looks good, but I'm not sure the many new features go well with the "2 month release" thing. I hope there are plans for a longer than usual testing period. Your announcement reads to me like it's going to be a regression bug release.
17. Allow multiple selective imports from different modules in a single import statement I have a bad feeling that that one is going to be a source of a raft of bugs for years to come.
Indeed, I had a bad feeling about it when reading the change log, didn't made sense first time I read it, and had to parse the line 2 times to understand what's up with it. In the light of pretty much heated arguments following your post I think it should be wise to deffer releasing this feature for a future time, maybe drag it through a DIP? This should also serve as a lesson to Walter and Andrei on how to handle this kind of changes, now that the community is a bit larger simple changes (at surface) have a bigger ripple effect. Thanks.
Feb 22
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
 17. Allow multiple selective imports from different modules in 
 a single import statement
Let me hopefully conclude this discussion :). We have an existing ambiguity in the language since at least dmd 1.0. This is unfortunate but seems costly to remove and minor in impact (after learning this behavior). import trees, fruits : apple, birds; A newcomer to D could rightfully conclude that comma is a module separator and the following is the correct syntax to import multiple symbols. import std.stdio, std.conv : to, std.conv : parse; Embracing that existing ambiguity to support multi-module selective imports wasn't well received, partly because it amplifies the ambiguity and partly because multi-module imports are frowned upon. On the plus side, we've understood that the actual wish for that syntax arised from scripting and example contexts, which might be better addressed by https://dlang.org/changelog/2.079.0.html#std-experimental-scripting, lazy import resolution by the compiler or a library, or automatic imports (https://github.com/CyberShadow/AutoFix). Furthermore there remain various ideas that would avoid the original ambiguity. Whether such changes are worthwhile is up for discussion and would benefit from someone taking the lead. I still think that local imports are nice for being explicit and toolable but have the downside of being brittle. Something like bash style expansion could help to hit a sweet spot IMHO. import std.{algorithm : {find, findSplit}, stdio : writeln}; import std.experimental.allocator.building_blocks.{free_list, region}; But certainly anything in that direction requires time and research, which I don't have for that topic. In hindsight the voting experiment on https://github.com/dlang/dmd/pull/6589 might have prevented useful early feedback and thinking. Given the effort required for a language change, it's seductive to streamline seemingly small changes, but it certainly increases the risk of design mistakes, thanks for appealing against this one. -Martin
Feb 23
next sibling parent Martin Nowak <code dawg.eu> writes:
On Friday, 23 February 2018 at 11:57:05 UTC, Martin Nowak wrote:
 But certainly anything in that direction requires time and 
 research, which I don't have for that topic.
Also new syntax would likely be met with strong resistance due to the amount of induced churn.
Feb 23
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 23 February 2018 at 11:57:05 UTC, Martin Nowak wrote:
 A newcomer to D could rightfully conclude that comma is a 
 module separator and the following is the correct syntax to 
 import multiple symbols.

     import std.stdio, std.conv : to, std.conv : parse;
What if you have something like import std.stdio, std.conv : to, parse; and there is a module at the top-level named parse?
Feb 23
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 2/23/18 8:13 AM, jmh530 wrote:
 On Friday, 23 February 2018 at 11:57:05 UTC, Martin Nowak wrote:
 A newcomer to D could rightfully conclude that comma is a module 
 separator and the following is the correct syntax to import multiple 
 symbols.

     import std.stdio, std.conv : to, std.conv : parse;
What if you have something like import std.stdio, std.conv : to, parse; and there is a module at the top-level named parse?
Then you have to import it on a separate line, or import it first. It's why I put one import per line. It's second nature to me, I don't even think of putting imports on the same line. But I think the better solution to this is instead making imports that collect other imports together. For instance, I rarely import std.algorithm.X, I usually use std.algorithm, even for selective imports. That seems more natural, and I don't have to look up which submodule it's in. -Steve
Feb 23
parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 23 February 2018 at 13:38:25 UTC, Steven Schveighoffer 
wrote:
 On 2/23/18 8:13 AM, jmh530 wrote:
 
 What if you have something like
 import std.stdio, std.conv : to, parse;
 and there is a module at the top-level named parse?
Then you have to import it on a separate line, or import it first. It's why I put one import per line. It's second nature to me, I don't even think of putting imports on the same line. But I think the better solution to this is instead making imports that collect other imports together. For instance, I rarely import std.algorithm.X, I usually use std.algorithm, even for selective imports. That seems more natural, and I don't have to look up which submodule it's in. -Steve
I'm all about one import per line and would have had no plans to use the syntax myself. Just trying to grok it.
Feb 23
prev sibling next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 23 February 2018 at 11:57:05 UTC, Martin Nowak wrote:
 On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
 Given the effort required for a language change, it's seductive 
 to streamline seemingly small changes, but it certainly 
 increases the risk of design mistakes, thanks for appealing 
 against this one.

 -Martin
Thanks to you, sincerely, It was a nice try to solve a problem, and trying to solve problems is the 'right thing to do'. I'm really pleased to see the D community developing the antibodies needed to support a strong and sane grown of D! /Paolo
Feb 23
prev sibling next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 2/23/18 6:57 AM, Martin Nowak wrote:
 On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
 17. Allow multiple selective imports from different modules in a 
 single import statement
Let me hopefully conclude this discussion :). We have an existing ambiguity in the language since at least dmd 1.0. This is unfortunate but seems costly to remove and minor in impact (after learning this behavior).     import trees, fruits : apple, birds; A newcomer to D could rightfully conclude that comma is a module separator and the following is the correct syntax to import multiple symbols.     import std.stdio, std.conv : to, std.conv : parse;
Maybe I misunderstand the problem here, birds must be a symbol under fruits in order for it to work (I tested it, and this is indeed the case). Your post seems to suggest that the birds module is imported (as it has nothing to do with fruits). Is that what you meant? In any case, I think we should not delay in discussing the merits of this, as Andrei seems to want this update, and we should have plenty of time now to discuss it before the 2.080 version.
 Embracing that existing ambiguity to support multi-module selective 
 imports wasn't well received, partly because it amplifies the ambiguity 
 and partly because multi-module imports are frowned upon.
I think the biggest problem really is that the problem it solves is so minor compared to the perceived ambiguity. As Andrei pointed out in the PR to revert, there really isn't a technical ambiguity. Only one possible interpretation makes sense. But to a human, it looks very ambiguous.
 On the plus side, we've understood that the actual wish for that syntax 
 arised from scripting and example contexts, which might be better 
 addressed by 
 https://dlang.org/changelog/2.079.0.html#std-experimental-scripting, 
 lazy import resolution by the compiler or a library, or automatic 
 imports (https://github.com/CyberShadow/AutoFix).
Yes, I think globbing together imports in one spot makes scripting and toy examples far easier to write. I'm reminded of my days at topcoder, when everyone had their "library" that just had all their proper imports and shorthand typedefs for things allowing them to code much faster during competitions.
 Furthermore there remain various ideas that would avoid the original 
 ambiguity. Whether such changes are worthwhile is up for discussion and 
 would benefit from someone taking the lead.
TBH, I'm somewhat opposed to mucking with import syntax. Seeing some of the examples of "all on one line" imports, it just looks so hard to parse through, I'd rather not worry about saving the keystrokes and line space.
 
 I still think that local imports are nice for being explicit and 
 toolable but have the downside of being brittle.
 Something like bash style expansion could help to hit a sweet spot IMHO.
 
      import std.{algorithm : {find, findSplit}, stdio : writeln};
      import std.experimental.allocator.building_blocks.{free_list, region};
For comparison: import std.algorithm: find, findSplit; import std.stdio : writeln; import std.experimental.allocator.building_blocks.free_list; import std.experimental.allocator.building_blocks.region; I don't find the latter extra verbose (except std.experimental, but that should go away eventually). When you list all the modules in order, it's easy to visually parse and see the differences. Perhaps a mechanism to specify submodules in a common large package may be useful.
 Given the effort required for a language change, it's seductive to 
 streamline seemingly small changes, but it certainly increases the risk 
 of design mistakes, thanks for appealing against this one.
And thanks for understanding the response and acting on it. -Steve
Feb 23
prev sibling parent Joakim <dlang joakim.fea.st> writes:
On Friday, 23 February 2018 at 11:57:05 UTC, Martin Nowak wrote:
 Furthermore there remain various ideas that would avoid the 
 original ambiguity. Whether such changes are worthwhile is up 
 for discussion and would benefit from someone taking the lead.
I really like psychoRabbit's array syntax suggestion. I see no reason the old syntax can't be kept around only for trailing symbols, while requiring the array syntax for selective import chains.
 I still think that local imports are nice for being explicit 
 and toolable but have the downside of being brittle.
 Something like bash style expansion could help to hit a sweet 
 spot IMHO.

     import std.{algorithm : {find, findSplit}, stdio : writeln};
     import 
 std.experimental.allocator.building_blocks.{free_list, region};

 But certainly anything in that direction requires time and 
 research, which I don't have for that topic.
Sure, it will require someone willing to implement it, not you.
 In hindsight the voting experiment on 
 https://github.com/dlang/dmd/pull/6589 might have prevented 
 useful early feedback and thinking.

 Given the effort required for a language change, it's seductive 
 to streamline seemingly small changes, but it certainly 
 increases the risk of design mistakes, thanks for appealing 
 against this one.
Reflecting further on your pull during this debate, my initial suggestion that it would cause a bunch of errors was probably overblown, readability is the main issue. The ambiguity you expanded on was fine if only limited to one set of trailing symbols, it became too hard to parse when a bunch of selective imports were chained. I hope someone steps us to implement this feature with better syntax, though it will require more effort than your simple patch, as I do see the need for it.
Feb 24
prev sibling next sibling parent reply Seb <seb wilzba.ch> writes:
On Monday, 19 February 2018 at 15:45:30 UTC, bachmeier wrote:
 On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to 
 the 77 contributors for this release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.079.0.html

 As usual please report any bugs at https://issues.dlang.org

 - ----

 This is probably the most feature-laden 2 month release ever.
 ...
This looks good, but I'm not sure the many new features go well with the "2 month release" thing. I hope there are plans for a longer than usual testing period. Your announcement reads to me like it's going to be a regression bug release.
FYI: _A lot_ of CI automation has been added in the past months. Most notably here is the Project Tester which runs the complete test suite of the most popular DUB projects out there. At the moment it tests ~40 projects and it has already caught a lot of problems _before_ being merged.
Feb 19
parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 19 February 2018 at 16:36:53 UTC, Seb wrote:
 FYI: _A lot_ of CI automation has been added in the past 
 months. Most notably here is the Project Tester which runs the 
 complete test suite of the most popular DUB projects out there.

 At the moment it tests ~40 projects and it has already caught a 
 lot of problems _before_ being merged.
+1
Feb 19
prev sibling parent Martin Nowak <code dawg.eu> writes:
On Monday, 19 February 2018 at 15:45:30 UTC, bachmeier wrote:
 This looks good, but I'm not sure the many new features go well 
 with the "2 month release" thing. I hope there are plans for a 
 longer than usual testing period. Your announcement reads to me 
 like it's going to be a regression bug release.
Well, we already run a lot of automated tests and the best way to help us avoiding regressions is by properly testing the beta against your code. Betas start on the 15th of every even month, releases are done 2 weeks later on the 1st of every odd month.
Feb 20
prev sibling next sibling parent reply Eugene Wissner <belka caraus.de> writes:
 fold is added to std.parallelism.TaskPool
std.parallelism.TaskPool.fold and reduce point to https://dlang.org/phobos-prerelease/std_parallelism_TaskPool.html#.fold and https://dlang.org/phobos-prerelease/std_parallelism_TaskPool.html#.reduce respectively, that can't be found, 404.
Feb 19
parent Seb <seb wilzba.ch> writes:
On Monday, 19 February 2018 at 16:14:46 UTC, Eugene Wissner wrote:
 fold is added to std.parallelism.TaskPool
std.parallelism.TaskPool.fold and reduce point to https://dlang.org/phobos-prerelease/std_parallelism_TaskPool.html#.fold and https://dlang.org/phobos-prerelease/std_parallelism_TaskPool.html#.reduce respectively, that can't be found, 404.
Thanks -> https://github.com/dlang/phobos/pull/6199 (The next time the changelog is updated, the links will be fixed)
Feb 19
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 02/19/2018 02:49 AM, Martin Nowak wrote:

Thanks Martin! You can add at least the following aliases for the 
contributor list:

acehreli: Ali Çehreli
aldacron: Mike Parker

Ali
Feb 19
parent reply Seb <seb wilzba.ch> writes:
On Monday, 19 February 2018 at 18:30:56 UTC, Ali Çehreli wrote:
 On 02/19/2018 02:49 AM, Martin Nowak wrote:

 Thanks Martin! You can add at least the following aliases for 
 the contributor list:

 acehreli: Ali Çehreli
 aldacron: Mike Parker

 Ali
... or you could have used your actual name for your GitHub commits ;-) https://github.com/dlang/tools/pull/322
Feb 19
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
And, I am quite sure: BBasile = Basile Burg.

(Sorry no PR, I am on my phone in a hotel.)
Feb 20
parent Basile B. <b2.temp gmx.com> writes:
On Tuesday, 20 February 2018 at 21:54:34 UTC, Bastiaan Veelo 
wrote:
 And, I am quite sure: BBasile = Basile Burg.

 (Sorry no PR, I am on my phone in a hotel.)
Yeah you're right Bastiaan, although for the NG i use a third variation.
Feb 20
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to 
 the 77 contributors for this release.

 - -Martin
Huh? Did I understand right? Just add an empty object.d into your project and --BetterC is now basically needless, plus the executable is most likely even smaller? And more functions to std.range, my favorite module, yes!
Feb 19
next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Monday, 19 February 2018 at 18:50:47 UTC, Dukc wrote:

 Huh? Did I understand right? Just add an empty object.d into 
 your project and --BetterC is now basically needless, plus the 
 executable is most likely even smaller?
Kindof, but not exactly. The -betterC switch still adds some nuance such as...
 assert failures are directed to the C runtime library
https://dlang.org/spec/betterc.html ... just to name one. Though, with 2.079, you should be much less constrained in your no-/partial- runtime implementation. For example, I'm exploring a minimal runtime implementation for using D on bare-metal microcontrollers (https://github.com/JinShil/stm32f42_discovery_demo) The device tree (i.e. bus/peripherals/registers/bitfields) is statically known at compile-time. I use this pattern to model the device tree... final abstract class RCC : Peripheral!(AHB1, 0x3800) { final abstract class CR : Register!(0x00, Access.Byte_HalfWord_Word) { alias PLLSAIRDY = Bit!(29, Mutability.r); alias PLLISAION = Bit!(28, Mutability.rw); } } https://github.com/JinShil/stm32f42_discovery_demo/blob/93f2c53578a18e8ce8e6a3985db14f361590f07f/source/stm32f42/rcc.d#L24 That would be impossible with -betterC, because -betterC doesn't support classes. I suspect others will find more compelling use cases. With 2.079 it may also be possible to implement certain features of D that are disabled in -betterC by providing custom implementations of runtime hooks (https://wiki.dlang.org/Runtime_Hooks) or other features in the runtime. I'm of the opinion, however, that with the right changes to the compiler-runtime coupling, as demonstrated in 2.079, a better C can be achieved without the -betterC compiler switch. There's still more work to be done, though, and the -betterC compiler switch will still have its uses. It should be noted, however, that it was the work done on -betterC that made the changes in 2.079 possible. Mike
Feb 19
parent reply meppl <mephisto nordhoff-online.de> writes:
On Monday, 19 February 2018 at 23:37:49 UTC, Mike Franklin wrote:
 On Monday, 19 February 2018 at 18:50:47 UTC, Dukc wrote:
 ...
Mike
"16.": https://dlang.org/changelog/2.079.0.html#minimal_runtime So, now someone could "easily" write his own memory managment for allocations who would be usually done by the default GC - e.g. classes?
Feb 20
next sibling parent Martin Nowak <code dawg.eu> writes:
On Tuesday, 20 February 2018 at 08:46:02 UTC, meppl wrote:
 So, now someone could "easily" write his own memory managment 
 for allocations who would be usually done by the default GC - 
 e.g. classes?
That isn't connected to object.d, but you can allocates classes where you want since ages. Just write a wrapper around `__traits(classInstanzeSize, ...)` or use http://code.dlang.org/packages/automem.
Feb 20
prev sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Tuesday, 20 February 2018 at 08:46:02 UTC, meppl wrote:

  "16.": https://dlang.org/changelog/2.079.0.html#minimal_runtime

 So, now someone could "easily" write his own memory managment 
 for allocations who would be usually done by the default GC - 
 e.g. classes?
Easily? unlikely, but it's probably possible. For example, whenever you use `new` to instantiate a class, it calls `_d_newclass` (https://github.com/dlang/druntime/blob/098a08a9593a8e265a9b02da55bda53393f3d5c1/src rt/lifetime.d#L66). You could potentially make that do something different. You will, unfortunately, need some implement some "infrastructure" to get it to work, namely `ClassInfo` which is an alias for `TypeInfo`. At the moment the runtime is heavily dependent on `TypeInfo` for type information that's already known at compile-time, which stinks. To mitigate that some of us are working on modifying the the compiler/runtime interface to use templates instead. That would allow implementing the runtime hooks without requiring so much of the infrastructure. Btw, this is all possible now even without the features of 2.079. 2.079 just allows one to do this more incrementally. It's still a long way from being a pleasant experience, but it's getting better. Mike
Feb 20
prev sibling parent Kagamin <spam here.lot> writes:
On Monday, 19 February 2018 at 18:50:47 UTC, Dukc wrote:
 Huh? Did I understand right? Just add an empty object.d into 
 your project and --BetterC is now basically needless, plus the 
 executable is most likely even smaller?

 And more functions to std.range, my favorite module, yes!
FWIW I used ldc with minimal runtime since 2013 or so, 2.079 is if you want to use dmd and classes.
Feb 20
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to 
 the 77 contributors for this release.

 [...]
This release is fantastic! In the change log information about lld linker is missing. Maybe you can add some info how to use it instead of link.exe (the OMF one). Kind regards André
Feb 19
next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 19/02/2018 21:17, Andre Pany wrote:
 On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to the 77 
 contributors for this release.

 [...]
This release is fantastic! In the change log information about lld linker is missing. Maybe you can add some info how to use it instead of link.exe (the OMF one). Kind regards André
LLD does not replace the OMF linker, but the MS linker for COFF. The Windows installer also comes with platform libraries built from the mingw definitions and a wrapper library for the VC distributable C runtime libraries. This allows using dmd with -m64 and -m32mscoff without having to install Visual Studio, the VC build tools or the Windows SDK. I'll add a PR for the changelog...
Feb 19
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 19 February 2018 at 21:50:02 UTC, Rainer Schuetze 
wrote:
 On 19/02/2018 21:17, Andre Pany wrote:
 On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak 
 wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to 
 the 77 contributors for this release.

 [...]
This release is fantastic! In the change log information about lld linker is missing. Maybe you can add some info how to use it instead of link.exe (the OMF one). Kind regards André
LLD does not replace the OMF linker, but the MS linker for COFF. The Windows installer also comes with platform libraries built
Just one step left to get an unified debug experience then: dward2 debug info for windows COFF objects. Is that right ?
Feb 19
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 20/02/2018 01:58, Basile B. wrote:
 On Monday, 19 February 2018 at 21:50:02 UTC, Rainer Schuetze wrote:
 On 19/02/2018 21:17, Andre Pany wrote:
 On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to the 77 
 contributors for this release.

 [...]
This release is fantastic! In the change log information about lld linker is missing. Maybe you can add some info how to use it instead of link.exe (the OMF one). Kind regards André
LLD does not replace the OMF linker, but the MS linker for COFF. The Windows installer also comes with platform libraries built
Just one step left to get an unified debug experience then: dward2 debug info for windows COFF objects. Is that right ?
I don't think that is planned in the near future. AFAICT DWARF debug support in dmd is not better than COFF (GDC might have an edge here), but using gdb instead of the VS debugger (or any other debugger suporting standard debug info) on Windows is pretty uncommon.
Feb 20
parent Basile B. <b2.temp gmx.com> writes:
On Tuesday, 20 February 2018 at 08:26:06 UTC, Rainer Schuetze 
wrote:
 On 20/02/2018 01:58, Basile B. wrote:
 On Monday, 19 February 2018 at 21:50:02 UTC, Rainer Schuetze 
 wrote:
 On 19/02/2018 21:17, Andre Pany wrote:
 On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak 
 wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ 
 to the 77 contributors for this release.

 [...]
This release is fantastic! In the change log information about lld linker is missing. Maybe you can add some info how to use it instead of link.exe (the OMF one). Kind regards André
LLD does not replace the OMF linker, but the MS linker for COFF. The Windows installer also comes with platform libraries built
Just one step left to get an unified debug experience then: dward2 debug info for windows COFF objects. Is that right ?
I don't think that is planned in the near future. AFAICT DWARF debug support in dmd is not better than COFF (GDC might have an edge here), but using gdb instead of the VS debugger (or any other debugger suporting standard debug info) on Windows is pretty uncommon.
I mean that by default we could have, under windows - the standard C lib interfaced to MinGW stuff (instead of digital mars snn.lib) - COFF objects, (instead of OMF) - DWARF2 debug infos, so that GDB can be used. GDB doesn't recognize OMF (and even if it did then there's the CV problem). FreePascal compiler follow this pattern: COFF everywhere, and DWARF as format of debug infos. What i meant is that DMD is at one step of being able to do the same, under windows even for COFF objects, debug infos are not DWARF format but the MS format. (unless i miss something, which is possible since i don't use win anymore).
Feb 20
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 19 February 2018 at 21:50:02 UTC, Rainer Schuetze 
wrote:
 On 19/02/2018 21:17, Andre Pany wrote:
 On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak 
 wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to 
 the 77 contributors for this release.

 [...]
This release is fantastic! In the change log information about lld linker is missing. Maybe you can add some info how to use it instead of link.exe (the OMF one). Kind regards André
LLD does not replace the OMF linker, but the MS linker for COFF. The Windows installer also comes with platform libraries built from the mingw definitions and a wrapper library for the VC distributable C runtime libraries. This allows using dmd with -m64 and -m32mscoff without having to install Visual Studio, the VC build tools or the Windows SDK. I'll add a PR for the changelog...
How does one keep on using Microsoft's linker? I've tried lld on Linux and while some binaries ran fine, others crashed. I don't trust it all right now. Atila
Feb 20
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 20/02/2018 9:49 AM, Atila Neves wrote:
 On Monday, 19 February 2018 at 21:50:02 UTC, Rainer Schuetze wrote:
 On 19/02/2018 21:17, Andre Pany wrote:
 On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to the 77 
 contributors for this release.

 [...]
This release is fantastic! In the change log information about lld linker is missing. Maybe you can add some info how to use it instead of link.exe (the OMF one). Kind regards André
LLD does not replace the OMF linker, but the MS linker for COFF. The Windows installer also comes with platform libraries built from the mingw definitions and a wrapper library for the VC distributable C runtime libraries. This allows using dmd with -m64 and -m32mscoff without having to install Visual Studio, the VC build tools or the Windows SDK. I'll add a PR for the changelog...
How does one keep on using Microsoft's linker? I've tried lld on Linux and while some binaries ran fine, others crashed. I don't trust it all right now. Atila
By the looks, nothing. https://github.com/dlang/dmd/blob/3030457738872ffe12e145dddb80b8b4cf766e4b/src/dmd/link.d#L1031 Also Windows and Linux support in lld may as well be equated to a completely different set of projects. "The linkers share the same design but share very little code. Sharing code makes sense if the benefit is worth its cost. In our case, the object formats are different enough that we thought the layer to abstract the differences wouldn’t be worth its complexity and run-time cost. Elimination of the abstract layer has greatly simplified the implementation." - https://lld.llvm.org/NewLLD.html
Feb 20
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On Tuesday, 20 February 2018 at 09:49:07 UTC, Atila Neves wrote:
 How does one keep on using Microsoft's linker? I've tried lld 
 on Linux and while some binaries ran fine, others crashed. I 
 don't trust it all right now.

 Atila
DMD prefers VC's linker if it is installed and will only fallback to lld-link.exe if no VC installation can be found. So there is a slight risk of accidentally using lld, when sth. in the VC detection code fails, but I hope that part is solid enough by now. Of course you can manully pick the linker using an env var, https://github.com/dlang/dmd/blob/38da6c2258c0ff073b0e86e0a1f6ba190f061e5e/ rc/dmd/link.d#L274, with the possibility to hard-coding the setting in your sc.ini. What were addressing here is the problem that in order to try D on Windows you need to go through the 30min. hoop of installing multi-GiB VC and Win SDK, or live with an outdated object file format and a hardly maintained linker. So this should improve the default experience on Windows. If someone wants to interact with C/C++, chances that VC is already installed are very high.
Feb 20
parent psychoRabbit <meagain meagain.com> writes:
On Tuesday, 20 February 2018 at 12:07:58 UTC, Martin Nowak wrote:
 What were addressing here is the problem that in order to try D 
 on Windows you need to go through the 30min. hoop of installing 
 multi-GiB VC and Win SDK, or live with an outdated object file 
 format and a hardly maintained linker.
 So this should improve the default experience on Windows.
 If someone wants to interact with C/C++, chances that VC is 
 already installed are very high.
only 30min? what world are you living in ;-) great work btw. looking forward to seeing it in action.
Feb 20
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On Monday, 19 February 2018 at 20:17:05 UTC, Andre Pany wrote:

You also need to install VC++ 2015 redistributable to run 
lld-link.exe. Let's see if we can lift that requirement until the 
release.
[18509 – [Beta 2.079] lld-link.exe needs 
msvcp140.dll](https://issues.dlang.org/show_bug.cgi?id=18509)
Feb 23
parent reply Martin Nowak <code dawg.eu> writes:
On Friday, 23 February 2018 at 18:13:01 UTC, Martin Nowak wrote:
 On Monday, 19 February 2018 at 20:17:05 UTC, Andre Pany wrote:

 You also need to install VC++ 2015 redistributable to run 
 lld-link.exe.
The x86 one btw. Also [18510 – [Beta 2.079] lld-link.exe fails to open obj file in subpath](https://issues.dlang.org/show_bug.cgi?id=18510) so it doesn't work with dub and likely fails for more complex applications.
Feb 23
parent Andre Pany <andre s-e-a-p.de> writes:
On Friday, 23 February 2018 at 19:06:42 UTC, Martin Nowak wrote:
 On Friday, 23 February 2018 at 18:13:01 UTC, Martin Nowak wrote:
 On Monday, 19 February 2018 at 20:17:05 UTC, Andre Pany wrote:

 You also need to install VC++ 2015 redistributable to run 
 lld-link.exe.
The x86 one btw. Also [18510 – [Beta 2.079] lld-link.exe fails to open obj file in subpath](https://issues.dlang.org/show_bug.cgi?id=18510) so it doesn't work with dub and likely fails for more complex applications.
Thanks a lot for the info. I will give it a try. Kind regards Andre
Feb 23
prev sibling next sibling parent Kirr <kkryukov gmail.com> writes:
On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:

 Windows got a new experimental toolchain based on the lld 
 linker and
 MinGW import libraries. This will hopefully replace OMF in the
 long-term without requiring heavy VC installations. Of course 
 VC will
 remain the primary toolchain on Windows. (still missing 
 changelog)
I've been waiting years for this day. One more friction point is removed for my use of D. Thanks!
Feb 22
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
 auto result = foo(), bar();
Does this compile? In variable declaration statement comma already has meaning as separator of declarators. Does it apply to enums too? This is difficult to parse.
Feb 22
parent reply Kagamin <spam here.lot> writes:
 auto result = foo(), bar();
Doesn't look like it works. --- int f(int a){ return a; } int main() { int a=f(0),f(1); //doesn't compile return 0; } --- int f(int a){ return a; } int main() { int a; a=f(0),f(1); assert(a==1); //fails return 0; } --- https://run.dlang.io/is/IgArs0
Feb 23
parent Seb <seb wilzba.ch> writes:
On Friday, 23 February 2018 at 17:47:08 UTC, Kagamin wrote:
 auto result = foo(), bar();
Doesn't look like it works. --- int f(int a){ return a; } int main() { int a=f(0),f(1); //doesn't compile return 0; } --- int f(int a){ return a; } int main() { int a; a=f(0),f(1); assert(a==1); //fails return 0; } --- https://run.dlang.io/is/IgArs0
Yeah that should result in an error: https://issues.dlang.org/show_bug.cgi?id=18508
Feb 23
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2018-02-19 11:49, Martin Nowak wrote:

 Glad to announce the first beta for the 2.079.0 release, ♥ to the 77
 contributors for this release.
The following is a regression that breaks DWT: extern (C) void foo(int) { } extern (C) void foo(double) { } The above used to compile but now results in: main.d(2): Error: function main.foo(double) cannot be overloaded with another extern(C) function at main.d(1) Was reported before the beta was released [1]. [1] https://issues.dlang.org/show_bug.cgi?id=18385 -- /Jacob Carlborg
Feb 23
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Friday, 23 February 2018 at 09:18:33 UTC, Jacob Carlborg wrote:
 On 2018-02-19 11:49, Martin Nowak wrote:

 Glad to announce the first beta for the 2.079.0 release, ♥ to 
 the 77
 contributors for this release.
The following is a regression that breaks DWT: extern (C) void foo(int) { } extern (C) void foo(double) { } The above used to compile but now results in: main.d(2): Error: function main.foo(double) cannot be overloaded with another extern(C) function at main.d(1) Was reported before the beta was released [1]. [1] https://issues.dlang.org/show_bug.cgi?id=18385
Overloaded `extern(C)` functions has also been reported as a bug at https://issues.dlang.org/show_bug.cgi?id=15217
Feb 23
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, February 23, 2018 10:08:58 Mike Franklin via Digitalmars-d-
announce wrote:
 On Friday, 23 February 2018 at 09:18:33 UTC, Jacob Carlborg wrote:
 On 2018-02-19 11:49, Martin Nowak wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to
 the 77
 contributors for this release.
The following is a regression that breaks DWT: extern (C) void foo(int) { } extern (C) void foo(double) { } The above used to compile but now results in: main.d(2): Error: function main.foo(double) cannot be overloaded with another extern(C) function at main.d(1) Was reported before the beta was released [1]. [1] https://issues.dlang.org/show_bug.cgi?id=18385
Overloaded `extern(C)` functions has also been reported as a bug at https://issues.dlang.org/show_bug.cgi?id=15217
Yeah, while I sympathize if this broken DWT, I don't see how this can actually work and have no idea how it every worked. You can't overload functions in C. That's why C++ and D name mangling adds type stuff to the name, but extern(C) tells the compiler to use C name mangling, so you lose that. - Jonathan M Davis
Feb 23
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.079.0.html
Second beta is published now. The website build server has some issues, so the website update is still stuck for a while. You can see a changelog preview here http://dtest.dlang.io/artifact/website-e5f8ee1211cb48bf97e0502f958179f8c82c9b35-ea6717f0f487cd7258756895d14da33f/web/changelog/2.079.0.html until it will be updated on http://dlang.org/changelog/2.079.0.html . Downloads can be found under http://downloads.dlang.org/pre-releases/2.x/2.079.0/ until they are linked on http://dlang.org/download.html#dmd_beta . Changes: https://github.com/dlang/dmd/compare/v2.079.0-beta.1...v2.079.0-beta.2 https://github.com/dlang/druntime/compare/v2.079.0-beta.1...v2.079.0-beta.2 https://github.com/dlang/phobos/compare/v2.079.0-beta.1...v2.079.0-beta.2 https://github.com/dlang/installer/compare/v2.079.0-beta.1...v2.079.0-beta.2 https://github.com/dlang/tools/compare/v2.079.0-beta.1...v2.079.0-beta.2 https://github.com/dlang/dlang.org/compare/v2.079.0-beta.1...v2.079.0-beta.2 https://github.com/dlang/dub/compare/v1.8.0-beta.1...v1.8.0-beta.2
Feb 24
parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Release candidate available now.

http://dlang.org/changelog/2.079.0.html
http://dlang.org/download.html#dmd_beta

- -Martin
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlqV4EgACgkQsnOBFhK7
GTmxyQ/9HSNmHvegTkIwheEcoHOMyn5s2QvK/8O1k07zfzLa6Bzhu55zEXlQGj1V
GDEl6YwGmzOcEF19XJnh/QOFMeNQJfwErfCjE2pJecN5aSeN87NapARzp1IZLXZw
avGJtlIPALpImYc7sg02syCRkg7399Bei5eAmgxsnbf0p5hx645brkL5v8Ko0stp
+PkGFM3ycAcxXq5iWcyxoIm1zgRKxzlP1xpJi1FIm9vMvT30nFmcF6vNz/IItMhv
bCSDaMU7GVsoRqD6SM9vnzCusbUJZpI6TkH0r+nlAMaU5UI8v9jG9+xQldxKiGhi
ScJY8kxMs4Bl2OS8ZTKqjgzJecejOuiRiseXgrQxRFWjyRVEOhZhh67q9HdgztCy
pc4OwRbwQEI3OR2jyNgbGqyc6eEQenvI4viQEjEONxAYR61hqDCUsWH7/K17z1Uu
4EmybgSiKowqvxF8Q6R7ZfsisAPzs3miSVjZ7pNSldQnrddUsisbfDYfHdexH9Aw
wPWp6OHsLjPRxihxCo8ThVSOjFgXh2+pu9Bzrj+QOa5pmha/hUfsRg6SfoRBsNnm
FopQXDDG4EuaTt64hvw5Phtm9AuUxzuD/49B98EN/YoosfmPFpuecXUX1FDHw33E
Vi467utwlLk5mbG5OBaBrpkpnFExyUn5vb1Ts6S+cCVVSbp58Po=
=nY5p
-----END PGP SIGNATURE-----
Feb 27
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
 Glad to announce the first beta for the 2.079.0 release, ♥ to 
 the 77 contributors for this release.

 [...]
On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote: Just for information. DWT doesn't build with 2.079 because of overloads not allowed . I'm not good enough to do something about it but only wanted to make people aware of it. I also opened an issue at the dwt project.
Feb 28
parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 02/28/2018 11:48 AM, Patrick Schluter wrote:
 Just for information. DWT doesn't build with 2.079 because of overloads
 not allowed . I'm not good enough to do something about it but only
 wanted to make people aware of it. I also opened an issue at the dwt
 project.
https://issues.dlang.org/show_bug.cgi?id=18385
Mar 02