Re: D vs nim
On Monday, 14 May 2018 at 06:14:02 UTC, Rel wrote: On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote: Funnily, none of these languages have a "static if" construct, nor do Rust, Swift and Nim. Not one that I could find, anyway. So what's a big deal in having 'static if' construct? Most of the new programming languages that compiles to native code like Nim, Crystal, Rust, Red and etc have good enough meta-programming support anyways. I recommend this talk to show what static if (among other static introspection tools) enables. https://www.youtube.com/watch?v=29h6jGtZD-U Cheers
Re: Module-level privacy
On Sunday, 13 May 2018 at 17:19:26 UTC, rumbu wrote: On Sunday, 13 May 2018 at 15:13:59 UTC, meppl wrote: Also, someone may say: I can see what happens in one and the same file. If there are two classes/structs in one file, they are "friends" and I dont need the "friend"-keyword anymore. Thats an argument, too. So, when you have 1000 classes, you just create 1000 files just to "unfriend" them :) If you have 1000 classes in a single module, you have bigger problems than encapsulation. :p -- Simen
Re: D vs nim
On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote: Funnily, none of these languages have a "static if" construct, nor do Rust, Swift and Nim. Not one that I could find, anyway. So what's a big deal in having 'static if' construct? Most of the new programming languages that compiles to native code like Nim, Crystal, Rust, Red and etc have good enough meta-programming support anyways.
Re: Building a standalone druntime for LDC
On Sunday, 13 May 2018 at 14:59:39 UTC, Seb wrote: On Sunday, 13 May 2018 at 13:37:06 UTC, A. Nicholi wrote: Hello, I am trying to build LDC’s druntime by itself (without phobos), but it seems that druntime expects to be built alongside DMD, which is strange considering I’m building LDC’s version of the druntime. Make says: “No rule to make target '../dmd/src/osmodel.mak'” That means that DMD hasn't been checked out in ../dmd relative to druntime as osmodel.mak is in DMD. More importantly, ldc's druntime fork doesn't use those Makefiles, they're just lying around from upstream. You can't use them to build a druntime for LDC, as they're missing LDC-specific files. He can use the tool David linked above or investigate the CMake targets that LDC uses: https://wiki.dlang.org/Building_LDC_from_source
Re: Bug?: Presence of "init()" Method Causes std.array.appender to Fail to Compile
On Monday, May 14, 2018 00:04:20 Uknown via Digitalmars-d wrote: > On Sunday, 13 May 2018 at 23:53:58 UTC, Vijay Nayar wrote: > > I encountered a very unexpected error when working on a > > project. It seems that the Appender and RefAppender structs > > created from the std.array.appender() method are sensitive to > > the mere presence of a method called "init()" on the element > > type of the array. > > > > [...] > > init is a reserved function. T.init is the initial value for a > type. int.init is 0 and float.init is NaN. Try changing your > function name to initialise or something like that. Yeah. It's been discussed that it should be illegal to declare a struct or class member named init, but that change has yet to happen. https://issues.dlang.org/show_bug.cgi?id=7066 https://issues.dlang.org/show_bug.cgi?id=14237 That mistake was even made in some places in druntime and Phobos (e.g. TypeInfo in druntime and DirEntry in Phobos), and it caused problems. Those uses had to be fixed before we could look at actually making it illegal, and AFAIK, they've all been fixed, but the compiler has yet to be changed. I don't know if a DIP would be required or not though before it could happen. It was kind of informally agreed that it should be illegal to declare init, but I don't think that it was ever officially agreed upon. Regarldless, declaring init just causes bugs, and code shouldn't do it. - Jonathan M Davis
Re: Exceptions without GC/Dynamic allocation. New proposal from Herb Sutter for C++
On Sunday, 13 May 2018 at 17:21:28 UTC, Ben Jones wrote: I think similar ideas have been discussed around here before (https://forum.dlang.org/thread/stlslhjndgugecvmb...@forum.dlang.org) but here's a new C++ proposal for overhauling their exception system to avoid dynamic allocation for exceptions. I guess it's not surprising that they're dealing with similar issues for exception handing as the D community. [...] Worth mentioning that DIP 1008 makes exceptions Ref-counted instead of GC managed, so exceptions can now be @nogc in D
Re: Bug?: Presence of "init()" Method Causes std.array.appender to Fail to Compile
On Sunday, 13 May 2018 at 23:53:58 UTC, Vijay Nayar wrote: I encountered a very unexpected error when working on a project. It seems that the Appender and RefAppender structs created from the std.array.appender() method are sensitive to the mere presence of a method called "init()" on the element type of the array. [...] init is a reserved function. T.init is the initial value for a type. int.init is 0 and float.init is NaN. Try changing your function name to initialise or something like that.
Bug?: Presence of "init()" Method Causes std.array.appender to Fail to Compile
I encountered a very unexpected error when working on a project.
It seems that the Appender and RefAppender structs created from
the std.array.appender() method are sensitive to the mere
presence of a method called "init()" on the element type of the
array.
Here is a minimal example:
```
import std.array;
struct S1 {
// The mere presence of this method causes the error, deleting
it fixes the error.
void init(string p1, int p2, int p3) { }
}
struct S2 {
S1[] a;
RefAppender!(int[]) getAppender() {
return appender(&a);
}
}
void main() { }
```
The compiler produces the following output:
```
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(2907): Error:
cannot have array of `void(string, int, int)`
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(2976): Error:
cannot have array of `inout void(string, int, int)`
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3369): Error:
template instance `std.array.Appender!(S1[])` error instantiating
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3879):
instantiated from here: `RefAppender!(S1[])`
onlineapp.d(12):instantiated from here: `appender!(S1[]*,
S1)`
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3429): Error:
cannot have array of `inout void(string, int, int)`
```
Is this a bug or a misunderstanding on my part?
Re: Module-level privacy
On Sunday, May 13, 2018 17:19:26 rumbu via Digitalmars-d wrote: > On Sunday, 13 May 2018 at 15:13:59 UTC, meppl wrote: > > Also, someone may say: I can see what happens in one and the > > same file. If there are two classes/structs in one file, they > > are "friends" and I dont need the "friend"-keyword anymore. > > Thats an argument, too. > > So, when you have 1000 classes, you just create 1000 files just > to "unfriend" them :) Which is basically what you get in Java, though no one should be putting 1000 classes in a single module anyway. But if you want to make it so that classes can't access each other's members while still making it possible to import them together, then all you have to do is have a module which publicly imports all of those other modules which have one class each. The only thing that you really lose with D's approach as opposed to friend is that D doesn't provide a way to mark something from another module as a friend. package at least partially solves that problem though. Really, what D went with is similar to what Java did, only it's more flexible, because it doesn't restrict what can go in a module, whereas Java only allows one public class per module and doesn't have any free functions. Ultimately, D's solution simplifies things over what C++ did with friends while giving you basically the same level of control. It's just that if you don't want something to be able to access the private members of a class or struct, that symbol must be in a separate module. So, if you _really_ don't want anything accessing the internals of your class or struct, but you want to be able to stick stuff in the same file, then that can get annoying, because you can't do that. But public imports let you make it so that you can still import them as one even if they're not actually in the same file, and many of us have found that having the default be that other stuff in the module can access the private members to be very useful - especially with regards to testing. I fully expect that if we added some sort of "super private" that really made it so that nothing outside a class or struct could access its members, almost no one would use it, and it wouldn't really solve much in the way of real problems, much as I'm sure that a few folks like KingJoffrey would be quite happy to have something like that. Ultimately, there are tradeoffs between what C++ did and what D did, and neither approach is perfect, so some folks are likely to be happier with one approach over the other, but overall, what D has done has worked extremely well for D. - Jonathan M Davis
Exceptions without GC/Dynamic allocation. New proposal from Herb Sutter for C++
I think similar ideas have been discussed around here before (https://forum.dlang.org/thread/stlslhjndgugecvmb...@forum.dlang.org) but here's a new C++ proposal for overhauling their exception system to avoid dynamic allocation for exceptions. I guess it's not surprising that they're dealing with similar issues for exception handing as the D community. I didn't dig too deep, but it looks like a pretty reasonable approach, except for requiring extra annotations for exceptions specification. Here's the r/cpp thread where they're discussing the paper (with a link): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf
Re: Module-level privacy
On Sunday, 13 May 2018 at 15:13:59 UTC, meppl wrote: Also, someone may say: I can see what happens in one and the same file. If there are two classes/structs in one file, they are "friends" and I dont need the "friend"-keyword anymore. Thats an argument, too. So, when you have 1000 classes, you just create 1000 files just to "unfriend" them :)
Re: Module-level privacy
On Sunday, 13 May 2018 at 05:51:07 UTC, KingJoffrey wrote: On Sunday, 13 May 2018 at 05:11:16 UTC, Neia Neutuladh wrote: [...] First, this thread was about extending the capabilities of classes in D with some new attribute/capability - sealed. I thought it was first important to point out, in this thread, as opposed to a separate thread, that classes in D are already problematic, because modules do not respect the encapsulation boundaries of classes, and any discussion about further extending classes should be approached with great caution - because the problem will only become even more entrenched. Second, writing a DIP is pointless, since Walter likes the idea that the module doesn't protect the encapsulation boundary of the class. Now if Walter thinks that's fine, what is a DIP going to do? I mean really. I have better things to do. Third, those who responded to my caution are the ones that should have created a separate thread, not me. Finally (and I do mean finally), my concern about the loss of the encapsulation boundary of classes in D, has a very real impact on the quality and maintainability of software systems developed in D. That the designer of D apparently thinks otherwise, baffles me. walter bright was not the only one who liked that idea of "only module level encapsulation". Its unfair to imply it like that. Also, someone may say: I can see what happens in one and the same file. If there are two classes/structs in one file, they are "friends" and I dont need the "friend"-keyword anymore. Thats an argument, too.
Re: Building a standalone druntime for LDC
On Sunday, 13 May 2018 at 13:37:06 UTC, A. Nicholi wrote: Hello, I am trying to build LDC’s druntime by itself (without phobos), but it seems that druntime expects to be built alongside DMD, which is strange considering I’m building LDC’s version of the druntime. Make says: “No rule to make target '../dmd/src/osmodel.mak'” That means that DMD hasn't been checked out in ../dmd relative to druntime as osmodel.mak is in DMD.
Re: Building a standalone druntime for LDC
On Sunday, 13 May 2018 at 13:37:06 UTC, A. Nicholi wrote: I am trying to build LDC’s druntime by itself (without phobos) […] Make says: “No rule to make target '../dmd/src/osmodel.mak'” LDC uses its own CMake-based build system for druntime/Phobos, see runtime/CMakeLists.txt I'm the main repository. The ldc-build-runtime tool streamlines (re)building certain runtime versions without having to manually manage the build process: https://wiki.dlang.org/Building_LDC_runtime_libraries —David
Re: Module-level privacy
On Sunday, 13 May 2018 at 05:51:07 UTC, KingJoffrey wrote: On Sunday, 13 May 2018 at 05:11:16 UTC, Neia Neutuladh wrote: Nobody's getting worked up about this, and nobody's telling you to stop talking about it. There have been suggestions that you write up a DIP for it. This is a standard process for suggesting improvements to D. Your complaint is about protection, not about classes. It should affect all definitions. Perhaps you simply don't expect type-level encapsulation for structs and top-level declarations. First, this thread was about extending the capabilities of classes in D with some new attribute/capability - sealed. I thought it was first important to point out, in this thread, as opposed to a separate thread, that classes in D are already problematic, because modules do not respect the encapsulation boundaries of classes, and any discussion about further extending classes should be approached with great caution - because the problem will only become even more entrenched. Second, writing a DIP is pointless, since Walter likes the idea that the module doesn't protect the encapsulation boundary of the class. Now if Walter thinks that's fine, what is a DIP going to do? I mean really. I have better things to do. Third, those who responded to my caution are the ones that should have created a separate thread, not me. Finally (and I do mean finally), my concern about the loss of the encapsulation boundary of classes in D, has a very real impact on the quality and maintainability of software systems developed in D. That the designer of D apparently thinks otherwise, baffles me. Walter is not the only person who accepts DIP and although he's the core head of D, it doesn't mean all his opinions are strictly 100% how D is going to evolve. I'm sure there are plenty of features that has been implemented that he does not entirely agree with and the same goes for others. If you can write a DIP and have a good use case for it, other than a very rare usecase, then it would most likely be accepted, IF the language would benefit from the addition. Writing posts about how you don't like feature X is way more useless than a DIP, because it will NOT change anything.
Building a standalone druntime for LDC
Hello, I am trying to build LDC’s druntime by itself (without phobos), but it seems that druntime expects to be built alongside DMD, which is strange considering I’m building LDC’s version of the druntime. Make says: “No rule to make target '../dmd/src/osmodel.mak'” Is it possible to build druntime by itself for LDC? Must I build LDC alongside it for every host platform, or may I just specify ‘-defaultlib=’ with a distro-provided LDC? How should I go about doing this?
