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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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

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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018