Re: Exception chaining and collectException
On Monday, 21 August 2017 at 20:15:53 UTC, Ali Çehreli wrote: On 08/19/2017 01:58 PM, Nemanja Boric wrote: C++ also provides a way to inspect if you're in the middle of the stack unwinding caused by an exception, to make this a bit more controllable, and I would think we should provide the similar primitive: . I don't know whether C++11 changed matters but according to popular C++98 wisdom, we were told "Don't use [std::uncaught_exception]": www.gotw.ca/gotw/047.htm Ali Rationale for changing this in C++17 is actually comming from Herb Sutter and it is referring to gotw47: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3614.pdf
Re: Exception chaining and collectException
On Tuesday, 22 August 2017 at 07:03:03 UTC, Nemanja Boric wrote: On Monday, 21 August 2017 at 20:15:53 UTC, Ali Çehreli wrote: On 08/19/2017 01:58 PM, Nemanja Boric wrote: C++ also provides a way to inspect if you're in the middle of the stack unwinding caused by an exception, to make this a bit more controllable, and I would think we should provide the similar primitive: . I don't know whether C++11 changed matters but according to popular C++98 wisdom, we were told "Don't use [std::uncaught_exception]": www.gotw.ca/gotw/047.htm Ali Rationale for changing this in C++17 is actually comming from Herb Sutter and it is referring to gotw47: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3614.pdf Sorry, on the phone, so I've pasted wrong link: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4152.pdf
Re: @safe(bool)
Am Sun, 20 Aug 2017 00:29:11 + schrieb Nicholas Wilson : > On Saturday, 19 August 2017 at 17:10:54 UTC, bitwise wrote: > > I'm still concerned about having to read code that's laced full > > of custom attributes, the resolution of which may span several > > files, templates, etc. > > > > I also think this type of thing could have a detrimental effect > > on modularity when you end up having to include "myAttribs.d" > > in every single file you want to work on. I would much rather > > have a flexible in-language solution, or a solution that didn't > > require me to define my own attributes. > > Having worked on a project with a lot of attributes, my > suggestion would be to import it via a package.d, you'll be > importing that anyway. +1 A bigger project /usually/ has some default imports. Typical use cases are unifying compiler versions and architectures, back-porting new Phobos features and custom error handling and logging. For example, in dub the modules in the "internal" package are imported into most of the bigger modules. You can also create a file template with documentation header, license and default imports if you need to create a lot of modules. -- Marco
Static inline field initialization
Because of D's static initialization of members, this assert
fails:
class Test {
ubyte[] buf = new ubyte[1000];
}
void main() {
auto a = new Test();
auto b = new Test();
assert(a.buf.ptr != b.buf.ptr);
}
This is bad, since;
* It is not how C++ works
* It introduces silent sharing of data
* It's usually not what you want
Shouldn't this at least generate a warning, or ideally not be
allowed?
Re: Static inline field initialization
On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnberg wrote:
Because of D's static initialization of members, this assert
fails:
class Test {
ubyte[] buf = new ubyte[1000];
}
void main() {
auto a = new Test();
auto b = new Test();
assert(a.buf.ptr != b.buf.ptr);
}
This is bad, since;
* It is not how C++ works
* It introduces silent sharing of data
* It's usually not what you want
Shouldn't this at least generate a warning, or ideally not be
allowed?
I agree that it can be confusing if you try to read it with C++
semantics [1]; the solution, however, imho is not to change D
semantics or throw warnings [2], but to refer to the D spec [3],
which states that static initialization of class members is used
instead of default initialization (before any constructors are
run). To me that means a statically initialized class field shall
have the same value in all class instances, i.e. it's not silent
sharing, you explicitly requested the sharing. If that doesn't
mean the same to others, the D spec wording should be updated to
be clearer on the subject.
If you don't want instances to share a field value, instead of
static initialization you can use constructor initialization [4]:
class Test
{
ubyte[] buf;
this()
{
buf = new ubyte[1000];
}
}
void main()
{
auto a = new Test();
auto b = new Test();
assert(a.buf.ptr != b.buf.ptr);
}
[1] D is not C++ and you shouldn't expect similar looking things
to behave the same
[2] Compiler warnings are (in my experience) ignored by people,
anyway
[3] https://dlang.org/spec/class.html#constructors
[4] https://dlang.org/spec/class.html#field-init
Re: Static inline field initialization
On Tuesday, 22 August 2017 at 12:20:45 UTC, Moritz Maxeiner wrote:
I agree that it can be confusing if you try to read it with C++
semantics [1]; the solution, however, imho is not to change D
semantics or throw warnings [2], but to refer to the D spec
[3], which states that static initialization of class members
is used instead of default initialization (before any
constructors are run). To me that means a statically
initialized class field shall have the same value in all class
instances, i.e. it's not silent sharing, you explicitly
requested the sharing. If that doesn't mean the same to others,
the D spec wording should be updated to be clearer on the
subject.
If you don't want instances to share a field value, instead of
static initialization you can use constructor initialization
[4]:
class Test
{
ubyte[] buf;
this()
{
buf = new ubyte[1000];
}
}
void main()
{
auto a = new Test();
auto b = new Test();
assert(a.buf.ptr != b.buf.ptr);
}
I know that it is according to the standard but since D has gone
out of it's way to make sure sharing doesn't occur otherwise, by
defaulting to TLS storage etc, I feel this breaks the "no
surprises" rule. I took me a long time to find this out and when
I mentioned it to other casual D programmers they also had no
idea this was how it worked.
Re: @safe(bool)
On 8/21/17 9:20 PM, Jonathan M Davis via Digitalmars-d wrote: Regardless, it means that I would need to run a tool to figure out which attributes actually applied to a function rather than just reading it like I could do now. And the fact that this is can be done with UDAs right now is _not_ a plus. I can understand wanting to reduce the number of attributes being manually applied to functions, but I think that hiding them with aliases and/or combined attributes is a maintenance nightmare and would argue that it's just plain bad practice. Not for or against the DIP, but this is already the case, due to block attributes. I have to search around the file to find out whether pure: is at the top, etc. In fact, I've made recommendations many times on PRs to add an attribute to a function, to find out it's already handled at the top. I would think documentation generation should solve the issues. -Steve
Re: Static inline field initialization
On 8/22/17 7:50 AM, Jonas Mminnberg wrote:
Because of D's static initialization of members, this assert fails:
class Test {
ubyte[] buf = new ubyte[1000];
}
void main() {
auto a = new Test();
auto b = new Test();
assert(a.buf.ptr != b.buf.ptr);
}
This is bad, since;
* It is not how C++ works
* It introduces silent sharing of data
* It's usually not what you want
Shouldn't this at least generate a warning, or ideally not be allowed?
https://issues.dlang.org/show_bug.cgi?id=2947
-Steve
Re: Static inline field initialization
On Tue, Aug 22, 2017 at 2:20 PM, Moritz Maxeiner via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnberg wrote: > >> ... > > > I agree that it can be confusing if you try to read it with C++ semantics > [1]; the solution, however, imho is not to change D semantics or throw > warnings [2], but to refer to the D spec [3], which states that static > initialization of class members is used instead of default initialization > (before any constructors are run). To me that means a statically > initialized class field shall have the same value in all class instances, > i.e. it's not silent sharing, you explicitly requested the sharing. > What? D spec does say nothing about sharing, its only speak about order, nothing else. So it is a buf from my POV.
Re: Static inline field initialization
s/buf/bug/ On Tue, Aug 22, 2017 at 3:52 PM, Daniel Kozak wrote: > On Tue, Aug 22, 2017 at 2:20 PM, Moritz Maxeiner via Digitalmars-d < > digitalmars-d@puremagic.com> wrote: > >> On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnberg wrote: >> >>> ... >> >> >> I agree that it can be confusing if you try to read it with C++ semantics >> [1]; the solution, however, imho is not to change D semantics or throw >> warnings [2], but to refer to the D spec [3], which states that static >> initialization of class members is used instead of default initialization >> (before any constructors are run). To me that means a statically >> initialized class field shall have the same value in all class instances, >> i.e. it's not silent sharing, you explicitly requested the sharing. >> > > What? D spec does say nothing about sharing, its only speak about order, > nothing else. So it is a buf from my POV. >
Re: Static inline field initialization
https://issues.dlang.org/show_bug.cgi?id=2947
Re: Static inline field initialization
On Tuesday, 22 August 2017 at 13:53:05 UTC, Daniel Kozak wrote: s/buf/bug/ On Tue, Aug 22, 2017 at 3:52 PM, Daniel Kozak wrote: On Tue, Aug 22, 2017 at 2:20 PM, Moritz Maxeiner via Digitalmars-d < digitalmars-d@puremagic.com> wrote: On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnberg wrote: ... I agree that it can be confusing if you try to read it with C++ semantics [1]; the solution, however, imho is not to change D semantics or throw warnings [2], but to refer to the D spec [3], which states that static initialization of class members is used instead of default initialization (before any constructors are run). To me that means a statically initialized class field shall have the same value in all class instances, i.e. it's not silent sharing, you explicitly requested the sharing. What? D spec does say nothing about sharing, its only speak about order, nothing else. So it is a buf from my POV. It doesn't have to and it's not a bug (though considering the replies in this thread the wording should be changed to include that): D's builtin arrays consist of a pointer and a length; the example thus *explicitly* initializes both the pointer and the length to the same (static) value for all instances (as per spec), sharing them. There is a bug [1] - as others have pointed out - that the static array isn't stored in TLS, but in global storage, however, but that doesn't apply in this single threaded case. [1] https://issues.dlang.org/show_bug.cgi?id=2947
Re: Static inline field initialization
On Tuesday, 22 August 2017 at 12:38:50 UTC, Jonas Mminnberg wrote:
On Tuesday, 22 August 2017 at 12:20:45 UTC, Moritz Maxeiner
wrote:
I agree that it can be confusing if you try to read it with
C++ semantics [1]; the solution, however, imho is not to
change D semantics or throw warnings [2], but to refer to the
D spec [3], which states that static initialization of class
members is used instead of default initialization (before any
constructors are run). To me that means a statically
initialized class field shall have the same value in all class
instances, i.e. it's not silent sharing, you explicitly
requested the sharing. If that doesn't mean the same to
others, the D spec wording should be updated to be clearer on
the subject.
If you don't want instances to share a field value, instead of
static initialization you can use constructor initialization
[4]:
class Test
{
ubyte[] buf;
this()
{
buf = new ubyte[1000];
}
}
void main()
{
auto a = new Test();
auto b = new Test();
assert(a.buf.ptr != b.buf.ptr);
}
I know that it is according to the standard but since D has
gone out of it's way to make sure sharing doesn't occur
otherwise, by defaulting to TLS storage etc,
While I can understand the sentiment, there is a difference
between sharing data between threads and sharing data between
class instances in the same thread, the latter of which is
occurring here.
There is a bug with static field initializers (as others have
pointed out), but it's about the fact that the array is stored in
global storage and not in TLS and doesn't apply in the example
above.
I feel this breaks the "no surprises" rule.
I took me a long time to find this out and when I mentioned it
to other casual D programmers they also had no idea this was
how it worked.
While I don't find how it works surprising personally (it's
consistent with how static initialization works everywhere else
in D) - in contrast to other subtleties in D - it might make be
sensible to include this in the Dlang tour.
Hello World
import std.stdio;
void main(char[][] args)
{
writefln("Hello World");
}
Community Rant
https://dlang.org/htod.html I click download and get an exe! And in the bugs section: No linux version. I'll start with the productive part. If anyone can point me out to the sources of htod I would love to compile for linux + osx. Any task seems more attractive to me than manually converting a 1000 line header to D. I'm a D lover and advocate. I actually get a salary writing D code for a cutting-edge startup. But lets be honest. If I was just interested to learn about this "modern system programming language" that is C++ done right, I would dismiss D very quickly. We need to get together as a community and rethink your priorities, because with problems like this we're making it very hard for newcomers to trust in this very poorly adapted language. Programming tools used by day to day programmers should be a priority. Because everyone expects valgrind to work. The standard library should be a priority. It's far from complete (hopefully my company will contribute in this respect in the near future). The DUB package repository is horrible! More often than not, the packages are so poorly written I end up just writing my own implementation. Adding the ability to "rate" packages would go a long way in improving the situation. I understand hacking the frontend is way more interesting to most of the community. But if we don't find the time to improve on our visibility and language maturity, D will never get the attention it deserves. P.S. I don't know you guys (except Ali and Andrei which I had the honor to meet). I don't follow the forums. I'm sure you often speak about these topics here. So - if I offended anyone know it's not personal (I don't know who you are). I just want to share my impressions and experience as an actual day to day D user.
Re: Community Rant
On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote: various. Out of interest did you pick up D before or after joining the start up? If before did you introduce D to them or were they already using it?
Re: Community Rant
On Tuesday, 22 August 2017 at 15:24:54 UTC, ixid wrote: On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote: various. Out of interest did you pick up D before or after joining the start up? If before did you introduce D to them or were they already using it? I work at weka.io. I learned D at weka, same as most of our workers (including the founders that looked for a powerful system programming language).
Re: Community Rant
Other possibilities can be dstep or cpp2d from visuald project. Though don't know if the latter can work on linux.
Re: @safe(bool)
On Tuesday, August 22, 2017 09:11:13 Steven Schveighoffer via Digitalmars-d wrote: > On 8/21/17 9:20 PM, Jonathan M Davis via Digitalmars-d wrote: > > Regardless, it means that I would need to run a tool to figure out which > > attributes actually applied to a function rather than just reading it > > like I could do now. And the fact that this is can be done with UDAs > > right now is _not_ a plus. I can understand wanting to reduce the > > number of attributes being manually applied to functions, but I think > > that hiding them with aliases and/or combined attributes is a > > maintenance nightmare and would argue that it's just plain bad > > practice. > > Not for or against the DIP, but this is already the case, due to block > attributes. I have to search around the file to find out whether pure: > is at the top, etc. In fact, I've made recommendations many times on PRs > to add an attribute to a function, to find out it's already handled at > the top. > > I would think documentation generation should solve the issues. Honestly, I tend to be against block attributes for this very reason, but at least with block attributes, you can grep/search the file and find the information. With this DIP, you potentially have to go looking in other libraries to figure out which attributes actually apply, and you have to track down every attribute on a function just to figure out whether a built-in attribute applies to it. And I bet the documentation generation (at least as it stands) would just put the custom attributes on there and not translate them to their constituent attributes. But even if it put all of the attributes on there individually, honestly, I think that it's a huge negative if I have to run the documentation generation to figure out what some code is doing. IMHO, I should be able to read the code and see what it's doing without running extra tools or searching through several other projects. Sometimes (particularly with more complicated code where you have to understand other functionality to understand the stuff in front of you), life doesn't work that way, but that should be the goal. And aliasing and combining attributes goes completely against that goal. Stuff like block attributes already harm it, but at least they're localized. - Jonathan M Davis
Re: Static inline field initialization
On Tuesday, 22 August 2017 at 14:53:21 UTC, Moritz Maxeiner wrote: There is a bug [1] - as others have pointed out - that the static array isn't stored in TLS, but in global storage, however, but that doesn't apply in this single threaded case. The initializer is copied from typeinfo, that can't refer to TLS data.
Re: Community Rant
On Tuesday, 22 August 2017 at 15:48:17 UTC, Kagamin wrote: Other possibilities can be dstep or cpp2d from visuald project. Though don't know if the latter can work on linux. So I guess someone should pick one and put it on the site. And make sure the source code is available. Having a link to a broken unusable utility on the main language website looks bad, to say the least.
Re: Community Rant
On Tuesday, August 22, 2017 15:14:33 Jonathan Shamir via Digitalmars-d wrote: > https://dlang.org/htod.html > > I click download and get an exe! > > And in the bugs section: > No linux version. > > I'll start with the productive part. If anyone can point me out > to the sources of htod I would love to compile for linux + osx. > Any task seems more attractive to me than manually converting a > 1000 line header to D. >From what I recall, it works pretty poorly anyway. As unpleasant as it may seem, the only way that I'd really consider converting a C header file would be by hand. If you want an automated solution though, dstep is probably the better way to go. http://code.dlang.org/packages/dstep I'm not sure tha anyone has touched htod in years. dstep certainly will have issues (as will any automated solution), but I believe that it's better maintained and would expect it to do a better job. > The DUB package repository is horrible! More often than not, the > packages are so poorly written I end up just writing my own > implementation. Well, that depends entirely on the individual package maintainers. At least there's actually a place to go find such projects now. It used to be that there really wasn't a good place to go find any D libraries, and there weren't very many around. So, while the situation may not be ideal and could certainly use some improvement, it has improved considerably in recent years. > Adding the ability to "rate" packages would go a > long way in improving the situation. It's been brought up before, and I expect that it will happen at some point. But it's the kind of thing that not many folks want to work on, so it's likely to suffer. It's probably the sort of thing where it would make sense for the dlang foundation to pay someone to do that now that they're able to do that at least occassionally. Someone would probably still have to show interest in doing the work though. > I understand hacking the frontend is way more interesting to most > of the community. But if we don't find the time to improve on our > visibility and language maturity, D will never get the attention > it deserves. Honestly, I think that the library gets more attention than the compiler. But in general, what gets done is what the person doing the work wants done regardless of whether that's the best thing to be doing for the community as a whole, and that's often how it goes with open source projects. Certainly, if you're looking for large additions to the standard library, that requires quite a big commitment in terms of time and effort to get it through the Phobos review process, and it seems that most folks these days simply don't want to do that. They'd rather just put their code up on code.dlang.org. A lot of small stuff does get done to Phobos all the time though. And if you compare what D's standard library has to what C++'s standard library has, D really doesn't look that bad. It has a lot of stuff that C++ doesn't. But there are some areas that C++ does better that we need to improve upon (e.g. containers - though supposedly Andrei and/or is supervising one of his students on them; they'd made some progress that they talked about at the last dconf, but whatever they're up to hasn't matured enough to make it into Phobos yet). If you're looking to have the amount of stuff that a language like Java or C# has in their standard libraries though, I think that you're forever going to be disappointed. There simply isn't enough manpower for that to happen, and it would likely require folks being paid fulltime to work on a lot of it, and that certainly isn't happening. Almost all of what gets done for the compiler and standard libraries is what folks are doing in their free time. - Jonathan M Davis
Re: Community Rant
On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote: The DUB package repository is horrible! More often than not, the packages are so poorly written I end up just writing my own implementation. Adding the ability to "rate" packages would go a long way in improving the situation. +1 There are lots of hidden gems in code.dlang.org and (maybe) some metrics to consider to measure relevance: frequency of tags/commits, number of contributors, Github stars or forks, number of dependent packages, download count per week...
Re: Static inline field initialization
On Tuesday, 22 August 2017 at 15:52:48 UTC, Kagamin wrote:
On Tuesday, 22 August 2017 at 14:53:21 UTC, Moritz Maxeiner
wrote:
There is a bug [1] - as others have pointed out - that the
static array isn't stored in TLS, but in global storage,
however, but that doesn't apply in this single threaded case.
The initializer is copied from typeinfo, that can't refer to
TLS data.
Which means it isn't easily fixable (or even feasible). I'd still
consider it a loophole in the type system right now as it allows
declaring global data mutably shared between threads without
`shared` or `__gshared` (the latter of which couldn't be applied
here, though).
I'd argue that - as new in this case doesn't allocate on the
heap, but in the resulting application's appropriate segments) -
it should work like this (from a language semantics standpoint):
---
class Test
{
shared(ubyte)[] buf = new shared(ubyte)[1000]; // classic
global storage, instances in all threads refer to the same static
array
}
class Test
{
ubyte[] buf = new ubyte[1000]; // thread local storage,
instances in the same thread refer to the same static array
}
---
Re: Static inline field initialization
On Tue, Aug 22, 2017 at 04:28:43PM +, Moritz Maxeiner via Digitalmars-d
wrote:
[...]
> I'd argue that - as new in this case doesn't allocate on the heap, but
> in the resulting application's appropriate segments) - it should work
> like this (from a language semantics standpoint):
>
> ---
>
> class Test
> {
> shared(ubyte)[] buf = new shared(ubyte)[1000]; // classic global
> storage, instances in all threads refer to the same static array
> }
>
> class Test
> {
> ubyte[] buf = new ubyte[1000]; // thread local storage, instances in the
> same thread refer to the same static array
> }
> ---
Sounds like a good idea. Please file this in bugzilla (if it isn't
already) so that it doesn't get lost in the ether.
T
--
Two wrongs don't make a right; but three rights do make a left...
HTOD
On 8/22/2017 8:14 AM, Jonathan Shamir wrote: https://dlang.org/htod.html I click download and get an exe! And in the bugs section: No linux version. I'll start with the productive part. If anyone can point me out to the sources of htod I would love to compile for linux + osx. Any task seems more attractive to me than manually converting a 1000 line header to D. You're right about htod, and it's on me. It's built out of the DMC++ front end. I haven't gotten around yet to releasing it as open source. The second problem is the DMC++ front end is tuned to deal with Windows compiler extensions, not Linux compiler extensions. So compiling it and running it on Linux will fail because every non-trivial C header file writer is unable to resist using every extension. There's also the gcc problem with its reliance on many hundreds (!) of predefined macros that are turned on/off by various gcc compiler switches. It's a madhouse. And, of course, every gcc on every platform has a different set of these. The situation was so bad that when I developed Warp (a fast C preprocessor) I left the predefined list up to the user to load from a special file. gcc on Ubuntu has 240 predefined macros when using the default switches. Who knows what the full list actually is. gcc -dM -E - https://stackoverflow.com/questions/2224334/gcc-dump-preprocessor-defines
Re: HTOD
On Tuesday, 22 August 2017 at 17:15:27 UTC, Walter Bright wrote: On 8/22/2017 8:14 AM, Jonathan Shamir wrote: [...] You're right about htod, and it's on me. It's built out of the DMC++ front end. I haven't gotten around yet to releasing it as open source. [...] Use Clang frontend?
Re: HTOD
On Tuesday, 22 August 2017 at 17:15:27 UTC, Walter Bright wrote: You're right about htod, and it's on me. It's built out of the DMC++ front end. I haven't gotten around yet to releasing it as open source. We can discuss possible ways of implementing htod. Instead, I'd rather discuss how we can make D more approachable and attractive to people thinking of picking up the language. In that respect, as far as htod goes, I think it should be removed from the site (it could still be available online). D can't have an official command line utility that doesn't work. Small steps.
Re: HTOD
On 8/22/17 1:15 PM, Walter Bright wrote: On 8/22/2017 8:14 AM, Jonathan Shamir wrote: https://dlang.org/htod.html I click download and get an exe! And in the bugs section: No linux version. I'll start with the productive part. If anyone can point me out to the sources of htod I would love to compile for linux + osx. Any task seems more attractive to me than manually converting a 1000 line header to D. You're right about htod, and it's on me. It's built out of the DMC++ front end. I haven't gotten around yet to releasing it as open source. I downloaded it. The exe is last modified April 28, 2010, corresponding with DMD version 2.044. This can't possibly produce valid D headers for 2.075.1. I think it should be either updated or removed from the web site. -Steve
Re: LDC, ARM: unnecessary default initialization
On Friday, 18 August 2017 at 12:09:04 UTC, kinke wrote: On Friday, 18 August 2017 at 09:42:25 UTC, Jack Applegame wrote: For some reason, the LDC default initializes the structure, even if initialization of all its members is specified as void. I believe that this is wrong. Afaik, this has been brought up multiple times already and is so by design. https://issues.dlang.org/show_bug.cgi?id=11331 https://issues.dlang.org/show_bug.cgi?id=11817 https://issues.dlang.org/show_bug.cgi?id=15951 It was discussed briefly during my DConf 2016 talk, and the status is that it is considered a performance bug. But it'll require spec changes / clarifications; Johannes listed a number already and maybe more it needed. - Johan
Re: LDC, ARM: unnecessary default initialization
On Tuesday, 22 August 2017 at 18:26:46 UTC, Johan Engelen wrote: It was discussed briefly during my DConf 2016 talk 2017.
Re: Community Rant
Am 22.08.2017 um 17:14 schrieb Jonathan Shamir: The DUB package repository is horrible! More often than not, the packages are so poorly written I end up just writing my own implementation. Adding the ability to "rate" packages would go a long way in improving the situation. We are working on this point. There will be some form of popularity and quality measures, as well as top lists to discover notable projects.
Re: @safe(bool)
On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote: [...] If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions. There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE.
Re: @safe(bool)
On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote: On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote: [...] If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions. There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE. You shouldn't rely on an IDE to compensate poor language design. That is coming from a guy who prefers IDE's.
Re: HTOD
On 2017-08-22 19:47, 12345swordy wrote: Use Clang frontend? DStep [1] is doing that. It handles both GCC and Microsoft extensions. [1] https://github.com/jacob-carlborg/dstep -- /Jacob Carlborg
Re: @safe(bool)
On 22.08.2017 21:46, 12345swordy wrote: On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote: On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote: [...] If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions. There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE. You shouldn't rely on an IDE to compensate poor language design. That is coming from a guy who prefers IDE's. I disagree with both the notion that this is poor language design and that an IDE is required to make sense out of code that uses the new feature.
Re: HTOD
On 8/22/2017 11:23 AM, Steven Schveighoffer wrote: I downloaded it. The exe is last modified April 28, 2010, corresponding with DMD version 2.044. This can't possibly produce valid D headers for 2.075.1. I think it should be either updated or removed from the web site. It doesn't correspond to the D version, it corresponds to the C compiler version, which is stable.
Re: HTOD
On 8/22/17 5:17 PM, Walter Bright wrote: On 8/22/2017 11:23 AM, Steven Schveighoffer wrote: I downloaded it. The exe is last modified April 28, 2010, corresponding with DMD version 2.044. This can't possibly produce valid D headers for 2.075.1. I think it should be either updated or removed from the web site. It doesn't correspond to the D version, it corresponds to the C compiler version, which is stable. But it is generating D code, no? -Steve
Re: HTOD
On 8/22/2017 2:50 PM, Steven Schveighoffer wrote: On 8/22/17 5:17 PM, Walter Bright wrote: On 8/22/2017 11:23 AM, Steven Schveighoffer wrote: I downloaded it. The exe is last modified April 28, 2010, corresponding with DMD version 2.044. This can't possibly produce valid D headers for 2.075.1. I think it should be either updated or removed from the web site. It doesn't correspond to the D version, it corresponds to the C compiler version, which is stable. But it is generating D code, no? Sure. And the C subset of D has been very stable, too.
Another reason to use BetterC
https://news.ycombinator.com/item?id=15075242
Re: Another reason to use BetterC
On Wednesday, 23 August 2017 at 01:22:44 UTC, Walter Bright wrote: https://news.ycombinator.com/item?id=15075242 Or better yet, full :D. I still find it strange how people willingly increase their own attack surface with such software, when even a single missed malware program is a total loss (since you can't know that a malware program missed by such software hasn't replaced your computer's firmware, or started asymmetrically encrypting your private data so you can't access it anymore, or sent out privileged information, etc.).
Re: @safe(bool)
On Tuesday, 22 August 2017 at 19:56:46 UTC, Timon Gehr wrote: I disagree with both the notion that this is poor language design and that an IDE is required to make sense out of code that uses the new feature. Indeed, I can't imagine a DIP suggesting to make core regular attributes, keyword like getting very far had those attributes been added after we got UDAs. While IDEs may be able to show you instantly what attributes a function has, so would the compiler (in the form of an errors message if you got it wrong, quality of said message notwithstanding), documentation, any dcd based tooling (or any other tools that can do symbol resolution) and code searches. If the tooling is insufficient for this use case, then it should be improved as this is a problem that is able to be solved completely by tooling. If you choose not to use the tooling, and it would solve this problem, then that is fine, but I don't think we should limit the design of the language because of that.
Re: @safe(bool)
On Tuesday, 22 August 2017 at 19:46:00 UTC, 12345swordy wrote: On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote: On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote: [...] If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions. There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE. You shouldn't rely on an IDE to compensate poor language design. That is coming from a guy who prefers IDE's. Platitudes cause poor language design, not the completely reasonable expectation of good tools.
Re: @safe(bool)
On Tuesday, 22 August 2017 at 19:56:46 UTC, Timon Gehr wrote: On 22.08.2017 21:46, 12345swordy wrote: On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote: On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote: [...] If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions. There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE. You shouldn't rely on an IDE to compensate poor language design. That is coming from a guy who prefers IDE's. I disagree with both the notion that this is poor language design and that an IDE is required to make sense out of code that uses the new feature. "Required" is a bit of a strong word here. In the absence of good practice, any language feature can be abused to make code confusing. Function overloading is a good example of a feature that is usable as is, but made much better with a good IDE. But the same way I wouldn't name every function in a class "performAction" and pass a 50 member enum to it to tell it what to actually do, I wouldn't have more than 4-5 different types of function attribute combinations, and if I did, I wouldn't spread them out among 10 different files. What little extra effort it takes to look up the attributes of a function in an atmosphere of good practice can easily be made up for with good tools, and no one _has_ to use bundled up attributes.
Future of export
I have as part of DIP 1012
```
enum SymbolExport
{
neither,
dynamicImport,
dynamicExport
}
alias dynamicImport = SymbolExport .dynamicImport;
alias dynamicExport = SymbolExport .dynamicExport;
```
to replace the `export` storage visibility, So that one can do
```
version(MyLib_Build)
enum MyLibExport = dynamicExport;
else
enum MyLibExport = dynamicImport;
// Exported when building the shared object,
//imported when linking against the shared object.
@MyLibExport void foo(int x) { ... }
```
However Martin said in
https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaR120 that "That's not what is planned for export"
Last I heard (from Benjamins Thaut's DConf 2016 talk) was that
nobody was using export because there was no corresponding import
and no way to switch between them. Benjamin suggested that making
it an attribute would fix that, hence it is part of DIP 1012.
What is planned for export?
