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: mysql-native v2.1.0-rc1: New features
On Friday, 23 February 2018 at 22:15:37 UTC, Nick Sabalausky (Abscissa) wrote: An all-D MySQL/MariaDB client library: https://github.com/mysql-d/mysql-native == [...] That's a very useful feature. Will simplify some code. As well as additional tools for optional micro-management of registering/releasing prepared statements. [...]
mysql-native v2.1.0-rc1: New features
An all-D MySQL/MariaDB client library:
https://github.com/mysql-d/mysql-native
==
Tagged 'v2.1.0-rc1', release candidate for v2.1.0, which mainly adds a
few new features, inlcuding greatly simplified shortcut syntax for
prepared statements (with automatic, implicit caching and re-use):
---
int i = 5;
string s = "Hello world";
conn.exec("INSERT INTO table_name VALUES (?, ?)", i, s);
conn.query("SELECT * FROM table_name WHERE id=? AND name=?", i, s);
// Also works:
Prepared stmt = conn.prepare("INSERT ...blah... (?, ?)");
conn.exec(stmt, i, s);
---
As well as additional tools for optional micro-management of
registering/releasing prepared statements.
Full changelog for this release is in the 'v2.1.x' branch:
https://github.com/mysql-d/mysql-native/blob/v2.1.x/CHANGELOG.md
Final v2.1.0 release is tentatively scheduled for one week from today.
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...
d.godbolt.org now supports DMD
Thanks to the work of Rabs Rincon [1] DMD is now supported on https://d.godbolt.org A simple example of comparing DMD's object code with LDC's + GDC's output: https://godbolt.org/g/EQCTNy [1] https://github.com/mattgodbolt/compiler-explorer/issues/306
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: dxml 0.2.0 released
On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis wrote: dxml 0.2.0 has now been released. Documentation: http://jmdavisprog.com/docs/dxml/0.2.0/ Github: https://github.com/jmdavis/dxml/tree/v0.2.0 Dub: http://code.dlang.org/packages/dxml - Jonathan M Davis This is absolutely awesome. It is a little low level (compared to SAX) so there is more to deal with, but having this provide a range (and flat) makes it so much clearer the ordering of elements. If I need to handle nesting then I can build that out, but if I don't I can just fly by the seat of my pants and grab the elements I want. This will definitely be my goto for XML parsing.
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: [Maybe OT] Hashcode with Google
On Friday, 23 February 2018 at 14:07:03 UTC, Andrea Fontana wrote: It could be interesting if a D-team would win this :) tl;dr: Google gives a coding problem, you have to solve it. Any programming language is accepted. You have to register your team. Details: https://hashcode.withgoogle.com/overview.html Previous problems: https://hashcode.withgoogle.com/past_editions.html Andrea Fontana seriously...hasn't google got a big enough foothold on the world? do we all need to keep encouraging it by particpating in its self-promoting, self-advertising ventures? google are masters of social engineering and the psychology of the gift economy. so I ask, what's the catch this time? oh.. you need to create a google account first it seems. Then they've got you, and all your data too.
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.
[Maybe OT] Hashcode with Google
It could be interesting if a D-team would win this :) tl;dr: Google gives a coding problem, you have to solve it. Any programming language is accepted. You have to register your team. Details: https://hashcode.withgoogle.com/overview.html Previous problems: https://hashcode.withgoogle.com/past_editions.html Andrea Fontana
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.
DConf 2018 Munich; The Venue
A bit of info to help kick start sightseeing plans in Munich and plan your stay at the NH Munich Messe. Don't forget, the submission deadline is this weekend: Feb 25 at midnight AOE. The blog: https://dlang.org/blog/2018/02/23/dconf-2018-munich-the-venue/ Reddit: https://www.reddit.com/r/d_language/comments/7zo3q1/dconf_2018_munich_the_venue/
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, 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
