Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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.'
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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.
2.079.0-rc.1 [Re: Beta 2.079.0]
-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-
2.079.0-beta.2 [Re: Beta 2.079.0]
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
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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 ;-)
Re: Beta 2.079.0
i don't understand whole theread. why all import must be written on one line? curent syntax very handy and readable.
Re: Beta 2.079.0
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 ;-)
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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 ;-)
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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
Re: lld-link.exe [in: Re: Beta 2.079.0]
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
Re: lld-link.exe [in: Re: Beta 2.079.0]
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.
lld-link.exe [in: Re: Beta 2.079.0]
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)
Re: Beta 2.079.0
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...
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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 :)
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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?
Re: Beta 2.079.0
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)
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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?
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
On Friday, February 23, 2018 09:48:33 Norm via Digitalmars-d-announce wrote: > [snip] > On Friday, 23 February 2018 at 04:06:23 UTC, psychoticRabbit > > wrote: > > Third, making D more and more like a quick scripting/hacking > > language (by removing or hiding so called 'noise', is not a > > good idea in my opinion. That too seemed to be a motivator for > > at some aspect of the change. > > This import feature and surrounding discussion I couldn't care > less about but I have to chime in and disagree with this > particular point. Ability to quickly script in D was a big > selling point for D at my workplace, I'd say *the* feature that > got uninterested developers listening and trying the language. > Being able to replace their Python scripts with a fast native > language that is also used for application and drivers > development was a winning formula. I don't know that scripts are really all that big a deal, since being able to slap #/usr/bin/env rdmd at the top really just saves you from having to compile the binary yourself, but I do use that functionality from time to time, and regardless of whether that functionality is supported, being able to write small programs to do stuff is invaluable. I do frequently use shell scripts when stuff is simple, but it doesn't take much before it's just easier to write them in D, and on Windows, I sure don't want to be writing batch scripts. So, being able to reasonably write small D programs to perform simple tasks is huge. And regardless of the scripting support, D itself makes that _way_ nicer than C/C++ does. Writing programs that are hundreds of thousands or millions of lines long is definitely not D's only use case. - Jonathan M Davis
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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
Re: Beta 2.079.0
[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
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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 ;-)
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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;
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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/
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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?
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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".
Re: Beta 2.079.0
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?
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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
Re: Beta 2.079.0
On Thu, Feb 22, 2018 at 09:42:13PM +, 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...
Re: Beta 2.079.0
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%
Re: Beta 2.079.0
On 2/22/2018 2:20 AM, Temtaime wrote: Fuck selective imports. Use of such words is not appreciated here. Please use professional demeanor.
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
On Thu, Feb 22, 2018 at 02:06:20AM +, 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 +, 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!
Re: Beta 2.079.0
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 :-)
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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)
Re: Beta 2.079.0
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!
Re: Beta 2.079.0
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];
Re: Beta 2.079.0
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 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. > >
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
Fuck selective imports. If you have tons of functions with same name it's your naming scheme mistake. If it makes compilation time slower, then fuck compiler, not import std;
Re: Beta 2.079.0
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 +, 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
Re: Beta 2.079.0
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 +, 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?
Re: Beta 2.079.0
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 +, 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
Re: Beta 2.079.0
On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote: On Tue, Feb 20, 2018 at 10:19:03PM +, 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
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
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 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? >
Re: Beta 2.079.0
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?
Re: Beta 2.079.0
On Wednesday, February 21, 2018 18:10:51 rjframe via Digitalmars-d-announce wrote: > On Wed, 21 Feb 2018 14:46:56 +, 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
Re: Beta 2.079.0
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.
Re: Beta 2.079.0
On Wednesday, 21 February 2018 at 18:10:51 UTC, rjframe wrote: On Wed, 21 Feb 2018 14:46:56 +, 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
Re: Beta 2.079.0
On Wednesday, 21 February 2018 at 16:58:22 UTC, H. S. Teoh wrote:
On Wed, Feb 21, 2018 at 02:46:56PM +, 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.
Re: Beta 2.079.0
On Wed, 21 Feb 2018 14:46:56 +, 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.
Re: Beta 2.079.0
On Wed, Feb 21, 2018 at 02:46:56PM +, 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
Re: Beta 2.079.0
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;
