Re: Last Call for Gripes and Wishes
On Monday, 20 March 2023 at 13:18:36 UTC, Mike Parker wrote: I'm on the road for the next three weeks. During the trip, I'll be organizing into some kind of coherent format all the gripes and wishes people have sent me at soc...@dlang.org. I'll be back home in the second week of April and hope to have everything publicly viewable shortly thereafter. So consider this the last call! If you haven't sent anything in yet, please see [my original post in the General forum](https://forum.dlang.org/thread/rcnrixuppxflnrhey...@forum.dlang.org) for the details. If you have sent something in, please feel free to send more. Consider March 31 the deadline. Remember, specific, actionable items are what we're looking for. Letting us know about more general complaints is fine, and I'll write something up about all of that, but the more specific you can be about your peeves, the more likely we'll be able to do something about them. Done
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: with Martin noting that this isn't a problem if you're properly encapsulating your types. While ignoring the issues/drawbacks that has been brought up when involving certain solutions to achieve this. I can't argue against a wall here. - Alex
Re: Silicon Valley D Meetup - April 15, 2021 - "Compile Time Function Execution (CTFE)"
On Tuesday, 27 April 2021 at 08:12:57 UTC, FeepingCreature wrote: On Monday, 26 April 2021 at 14:01:37 UTC, sighoya wrote: On Monday, 26 April 2021 at 13:17:49 UTC, FeepingCreature wrote: On Sunday, 25 April 2021 at 21:27:55 UTC, sighoya wrote: On Monday, 19 April 2021 at 06:37:03 UTC, FeepingCreature wrote: Native CTFE and macros are a beautiful thing though. What did you mean with native? When cx needs to execute a function at compiletime, it links it into a shared object and loads it back with dlsym/dlopen. So while you get a slower startup speed (until the cache is filled), any further calls to a ctfe function run at native performance. Ah okay, but can't Dlang runtime functions not anyway called at compile time with native performance too? So generally, cx first parses the program, then filters out what is a macro, then compiles all macro/ctfe functions into shared lib and execute these macros from that lib? Sorta: when we hit a macro declaration, "the module at this point" (plus transitive imports) is compiled as a complete unit. This is necessary cause parser macros can change the interpretation of later code. Then the generated macro object is added to the module state going forward, and that way it can be imported by other modules. Isn't it better to use the cx compiler as a service at compile time and compile code in-memory in the executable segment (some kind of jiting I think) in order to execute it then. I think the cling repl does it like that. That would also work, I just went the path of least resistance. I already had an llvm backend, so I just reused it. Adding a JIT backend would be fairly easy, except for the part of writing and debugging a JIT. :P And how does cx pass type objects? By reference. :) Since the compiler is in the search path, you can just import cx.base and get access to the same Type class that the compiler uses internally. In that sense, macros have complete parity with the compiler itself. There's no attempt to provide any sort of special interface for the macro that wouldn't also be used by compiler internal functions. (There's some class gymnastics to prevent module loops, ie. cx.base defines an interface for the compiler as a whole, that is implemented in main, but that is indeed also used by the compiler's internal modules themselves.) The downside of all this is that you need to parse and process the entire compiler to handle a macro import. But DMD gives me hope that this too can be made fast. (RN compiling anything that pulls in a macro takes about a second even with warm object cache.) It is better to use an existing jit framework then to build one on your own with regards to the JIT backend. -Alex
Re: Beta 2.096.0
On Monday, 1 March 2021 at 01:02:48 UTC, Meta wrote: On Sunday, 28 February 2021 at 11:56:28 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.096.0 release, ♥ to the 53 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.096.0.html As usual please report any bugs at https://issues.dlang.org -Martin "Support for instantiating local and member templates with local symbols was implemented in DMD 2.087.0. However, the implementation was incompatible with GDC and LDC backends. In order to maintain feature parity among D implementations, this improvement has been deprecated, and may be removed from a future DMD release." Urgh, so sad this was deprecated. Is the implementation being redone at some point? To my understanding, the answer is no. It been brought up in discord that a proper fix consist of the templates having is own vthis. -Alex
Re: DIP 1030-- Named Arguments--Formal Assessment
On Thursday, 17 September 2020 at 12:59:05 UTC, Mike Parker wrote: On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote: DIP 1030, "Named Arguments", has been accepted. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1030.md YES, YES, YES, I had argue in favor of this dip so hard in the past years. Thank you Walter. -Alex
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Monday, 15 June 2020 at 20:51:38 UTC, Stefan Koch wrote: On Monday, 15 June 2020 at 20:47:16 UTC, 12345swordy wrote: On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: https://code.dlang.org/packages/tardy https://github.com/atilaneves/tardy [...] Wouldn't a top type be a better way to achieve this? -Alex the Talias in type functions is a top type. (If I do understand correctly that it is something it's another word for an Any type.) it's a pain in the ass, to work with if you are not dynamically typed language. Speaking of type functions, have you been working on a dip for that? I am quite curious to see what it looks like currently. -Alex
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: https://code.dlang.org/packages/tardy https://github.com/atilaneves/tardy [...] Wouldn't a top type be a better way to achieve this? -Alex
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Friday, 22 May 2020 at 00:50:00 UTC, Walter Bright wrote: On 5/21/2020 2:44 PM, Joseph Rushton Wakeling wrote: One concern here is that these responses are scattered across different parts of a long discussion thread. So it probably would be a good idea for the acceptance to be accompanied by an explanation of what the major objections were to the DIP, and why they were discounted. It's not so different from the way that, at the end of a talk or presentation, it's a good idea to recap the key points that have already been covered. Fair enough. I'll do so. Stay tuned. Thank you. Having an explanation on why the DIP is accepted despite being highly controversial would be sufficient. -Alex
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 13:51:34 UTC, Mike Parker wrote: DIP 1028, "Make @safe the Default", has been accepted without comment. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1028.md I guess they be more open to dips that fixes holes in the "safe by default" feature then.
Re: DIP 1027---String Interpolation---Format Assessment
On Monday, 24 February 2020 at 19:45:49 UTC, Adam D. Ruppe wrote: On Monday, 24 February 2020 at 19:35:16 UTC, Walter Bright wrote: Having the compiler lower string interpolation to some hidden template is - AST macros. We're not doing AST macros. This is untrue. Hidden user-defined semantics are not for D. We are NOT calling for this. What, exactly, do you think we're proposing? I knew it. You needs an actual implementation here, to show walter what you are talking about. This reminds me of the whole mangle only discussion a while back. It took an actual PR for Walter to accept it instead of days arguing with him. Let get to work on this. -Alex
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Wednesday, 23 October 2019 at 15:31:24 UTC, Exil wrote: D isn't a systems programming language "“But D has a GC!”, I hear you exclaim. Yes, but it’s also a systems programming language with value types and pointers, meaning that today, D isn’t memory safe. DIP1000 was a step in the right direction, but we have to be memory safe unless programmers opt-out via a “I know what I’m doing” @trusted block or function. This includes transitioning to @safe by default." https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/ -Alex
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote: Not to mention the problem is actually solved just by using the GC. The d language is marked as a system programming language. The GC is not going to cut it to a lot of people.(Did you forget the whole betterC flag?) -Alex
Re: Symantec has been sold to Broadcom
On Thursday, 8 August 2019 at 23:46:38 UTC, Walter Bright wrote: https://finance.yahoo.com/news/broadcom-buy-symantec-enterprise-division-201706500.html It's the end of an era. Symantec bought my company, Zortech, and now is bought in return. The D community, and myself personally, owe a debt of gratitude to Symantec. Thank you, Symantec! What does this mean for the future of the D language?
Re: Ownership and Borrowing in D
On Saturday, 20 July 2019 at 21:56:50 UTC, Walter Bright wrote: On 7/20/2019 5:42 AM, Sebastiaan Koppe wrote: Anyway my question is whether the ownership and borrowing semantics ever gets applied to non-pointers? Currently, no. The programmer would be expected to include the correct copyctor/opAssign/destructors which would take care of it. We're likely going to add a move constructor, too. Make sure that it is a separate pull request from the dip, as c++ std::string binding is currently block by the lack of this.
Re: The D Programming Language has been accepted as a GSoC 2019 organization
On Tuesday, 26 February 2019 at 22:34:45 UTC, Seb wrote: Hi all, I have some very exciting news to share. [...] That is great news! What is not great news is that I am no longer a student and I couldn't attend to this even though I want to.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Friday, 1 February 2019 at 23:24:44 UTC, Olivier FAURE wrote: On Friday, 1 February 2019 at 09:10:15 UTC, aliak wrote: Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a getter? For it not to be a compile error pt.x should also have a setter, in which case the code needs to be lowered to something else: The thing is, D doesn't really differentiate between a getter and any other method. So with DIP-1016, when given doubleMyValue(pt.x); The compiler would assume the programmer means - Call pt.x() - Store the result in a temporary - Pass that temporary as a ref parameter to doubleMyValue At no point is the compiler aware that the user intends for x to be interpreted as a getter. Languages like c# solve this problem by disallowing passing property to ref parameter arguments.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Friday, 1 February 2019 at 15:58:50 UTC, Aliak wrote: On Friday, 1 February 2019 at 14:41:52 UTC, 12345swordy wrote: On Friday, 1 February 2019 at 11:48:51 UTC, Timon Gehr wrote: On 01.02.19 10:10, aliak wrote: [...] http://wilzbach.github.io/d-dip/DIP24 I'm not sure your rewrite is good though, because it does not preserve aliasing during the function call. Not only that, but C# forbids you passing properties as an ref/out parameter. (The properties should be redefined as accessor, such that you can't take the address of it) -Alex By properties I mean accessors? I don’t mean normal fieldsat least. Or does c# have a distinction between normal member variables, properties, and accessors? https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Friday, 1 February 2019 at 11:48:51 UTC, Timon Gehr wrote:
On 01.02.19 10:10, aliak wrote:
Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a
getter? For it not to be a compile error pt.x should also have
a setter, in which case the code needs to be lowered to
something else:
{
auto __temp = pt.x;
doubleMyValue(__temp);
pt.x = __temp;
}
I believe this is something along the lines of what Swift and
C# do as well.
Or something... a DIP to fix properties anyone? :)
http://wilzbach.github.io/d-dip/DIP24
I'm not sure your rewrite is good though, because it does not
preserve aliasing during the function call.
Not only that, but C# forbids you passing properties as an
ref/out parameter.
(The properties should be redefined as accessor, such that you
can't take the address of it)
-Alex
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Wednesday, 30 January 2019 at 18:29:37 UTC, Manu wrote:
On Wed, Jan 30, 2019 at 9:20 AM Neia Neutuladh via
Digitalmars-d-announce
wrote:
On Wed, 30 Jan 2019 09:15:36 -0800, Manu wrote:
> Why are you so stuck on this case? The DIP is about
> accepting rvalues,
> not lvalues...
> Calling with 'p', an lvalue, is not subject to this DIP.
The result of a CastExpression is an rvalue. An implicit cast
is a compiler-inserted CastExpression. Therefore all lvalues
with a potential implicit cast are rvalues.
But there's no existing language rule that attempts to perform
an
implicit cast where an lvalue is supplied to a ref arg...?
Why is the cast being attempted?
Because of the rewrite that your proposed in your dip.
void fun(ref int x);
fun(10);
{
T __temp0 = void;
fun(__temp0 := 10);
}
lets replace 10 with a short variable named: S
void fun(ref int x);
fun(S)
{
T __temp0 = void;
fun(__temp0 := S);
}
fun(__temp0 := S) This is where the cast is being attempted. As
__temp0 is aninteger type and S is a
short type
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Wednesday, 30 January 2019 at 16:47:48 UTC, Don wrote: On Wednesday, 30 January 2019 at 13:58:38 UTC, 12345swordy wrote: I do not accept gut feeling as a valid objection here. The current workarounds is shown to be painful as shown in the dip and in the discussions that it currently link. That *the* motivation here. Like I said previously I am on the reviews side and that's it. In terms of what exactly? Walter had stated they do not rejected the dip in principle. You apparently *do* rejected it in principle, from judging your posts here. By the way I don't like your tone when you say: "I do not accept gut feeling as a valid objection here". If you stated that you think it a bad/good idea without explaining why you think it. That is what I call "gut feeling" Alright we're talking about a change that have been on hold for almost 10 years, if it was simple it would already been done. The current dip system didn't exist 10 years prior. I wouldn't say that things are already done due to them being simple, as there are quite number of "simple" features that wasn't implemented already (Looking at you tuples). -Alex
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Wednesday, 30 January 2019 at 04:34:46 UTC, Don wrote: On Wednesday, 30 January 2019 at 03:01:36 UTC, 12345swordy wrote: On Wednesday, 30 January 2019 at 00:25:17 UTC, Don wrote: But what I fail to see is why can't the programmer solve this themselves instead of relying on a new feature that would cause more harm? Donald. ...Did you even read the arguments in the dip? This has been discuss quite a lot in the forums, it even gives you links to them. Well, I read the DIP and the whole forum discussion back in the day, and again I think this will create more harm than benefits the way it was proposed. Donald. I do not accept gut feeling as a valid objection here. The current workarounds is shown to be painful as shown in the dip and in the discussions that it currently link. That *the* motivation here. I am familiar with the author here, he is very involved with the C++<->D compatibility side of things. He knows the pain from first hand experience. -Alex
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Wednesday, 30 January 2019 at 00:25:17 UTC, Don wrote: But what I fail to see is why can't the programmer solve this themselves instead of relying on a new feature that would cause more harm? Donald. ...Did you even read the arguments in the dip? This has been discuss quite a lot in the forums, it even gives you links to them.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 23:43:21 UTC, Walter Bright wrote: It's no problem if you want to rework the existing text, just submit it as a new DIP. And wait for another 180+ days for a fix? Come on dude, can you understand the frustration being display here?
Re: My Meeting C++ Keynote video is now available
On Tuesday, 15 January 2019 at 17:29:12 UTC, welkam wrote: On Tuesday, 15 January 2019 at 11:59:58 UTC, Atila Neves wrote: He's not saying "kill classes in D", he's saying an OOP system in D could be implemented from primitives and classes don't need to be a language feature, similar to CLOS in Common Lisp. For some people writing OOP means writing keyword class. I am not interested in OOP as a library feature rather then a built in feature. Let not repeat the same mistakes as c++. If there were a dip that involves deprecating class, expect me to be very vocal in regards to opposing it.
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 10:06:48 UTC, Mike Franklin wrote: On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote: When something like an object system is made part of the language (or at the very least, the standard library), it becomes a focal point [2] that the community can coordinate around. Due to the diverse, distributed nature of any programming-language community, trying to coordinate through explicit communication is not really a viable option, so having these kinds of focal points is very important if we want to be able to work together on anything. [1] http://winestockwebdesign.com/Essays/Lisp_Curse.html [2] https://en.wikipedia.org/wiki/Focal_point_(game_theory) I think D's structs are a sufficient object system for such a focal point. With design by introspection, `alias`, templates, `alias this`, `static if`, CTFE, mixins, and a few new D features, classes would be unnecessary. Rust and Zig are pretty good examples of this. D's implementation could even be improved to keep its runtime, yet still allow D to be used as I'm suggesting, without introducing any breakage for anyone. I made some significant progress in that direction when I was working on the compiler in the 2017~2018 timeframe, but my abilities ultimately fell short, and I couldn't see a way forward without support. Mike Killing classes will kill my interest and investment in D. Alex.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 12:57:03 UTC, Atila Neves wrote: On Tuesday, 11 December 2018 at 12:52:20 UTC, Adam D. Ruppe wrote: On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ If @property worked for a thing to return a delegate, it would be useful. But n, we got worked up over syntax and forgot about semantics :( @property is useful for setters. Now, IMHO setters are a code stink anyway but sometimes they're the way to go. I have no idea what it's supposed to do for getters (nor am I interested in learning or retaining that information) and never slap the attribute on. My view of getters is that they serve as a contract of between contractor and client stating "You can't modify this value, I however can".
Re: DLP identify leaf functions
On Friday, 30 November 2018 at 20:10:05 UTC, Jacob Carlborg wrote: I would like to announce a new project I've started, called DLP (D Language Processing). Currently it's quite experimental but the idea is that it would contain a collection of commands for inspecting D code in various ways. It uses the DMD frontend as a library (the Dub package) to process D code. This first release only contains one command, "leaf-functions". It will print out all leaf functions to standard out. A "leaf function" is considered a function that doesn't call any other functions or doesn't have a body. The use case for this is if you have a code base that you would like to add attributes to. Since most attributes causes the function they're attached to be constraint in which other functions they can call, "@nogc" functions can only call other "@nogc" functions, "pure" functions can only call other "pure" functions and so on. Therefore it makes most sense when starting to add attributes to a code base to start with the leaf functions, the functions that don't call any other functions. Pre-compiled binaries are available for macOS, Linux and Windows. https://github.com/jacob-carlborg/dlp In all honestly I think the compiler should make some test with regards to the system attrubutes and create attributes if it passes or fails. @unpure, @unsafe, @gc. The downside of this is the increase of compile time.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Wednesday, 14 November 2018 at 18:11:59 UTC, Neia Neutuladh wrote: On Tue, 13 Nov 2018 20:27:05 -0800, Walter Bright wrote: There have been various attempts over the years to "fix" various things in the D matching system by adding "just one more" match level. I kind of feel like, if something would be confusing like this, maybe the compiler shouldn't be making an automatic decision. Not "just one more" match level, but just...don't match. If there are multiple matching overloads, just error out. Don't try to be clever and surprise people, just tell the user to be more explicit. That type of behavior is best left to the programmer defining the public interface. -Alex
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Tuesday, 13 November 2018 at 17:50:20 UTC, Neia Neutuladh
wrote:
On Tue, 13 Nov 2018 09:46:17 -0500, Steven Schveighoffer wrote:
Maybe the biggest gripe here is that enums don't prefer their
base types over what their base types convert to. In the
developer's mind, the conversion is:
A => int => (via VRP) short
which seems more complex than just
A => int
It affects explicit casts too:
void foo(short a) { writefln("short %s", a); }
void foo(int a) { writefln("int %s", a); }
foo(cast(int)0); // prints: short 0
Ok, now that has got to be a bug. If you explicit cast the number
to an integer then you expect the overload function with int to
be called.
-Alex
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 21:38:27 UTC, Walter Bright wrote: On 11/12/2018 8:28 AM, 12345swordy wrote: The issue that I see is unintended implicit conversation when passing values to functions that have both int and bool overloads. The exact same thing happens when there are both int and short overloads. The underlying issue is is bool a one bit integer type, or something special? D defines it as a one bit integer type, fitting it into the other integer types using exactly the same rules. If it is to be a special type with special rules, what about the other integer types? D has a lot of basic types :-) Ok, you don't want to introduce special rules for integers, and that understandable. However there needs be a tool for the programmer to prevent unwanted implicit conversation when it comes to other users passing values to their public overload functions.(Unless there is already a zero cost abstraction that we are not aware of). -Alex
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 21:29:20 UTC, Walter Bright wrote: I once worked with software that defined true as 0 and false as 1 OK, I got to know what language you were using at the time, because I am curious at what other oddities does it have. -Alex
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 10:05:09 UTC, Jonathan M Davis wrote: On Monday, November 12, 2018 2:45:14 AM MST Mike Parker via Digitalmars-d- announce wrote: DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool, has been rejected, primarily on the grounds that it is factually incorrect in treating bool as a type distinct from other integral types. *sigh* Well, I guess that's the core issue right there. A lot of us would strongly disagree with the idea that bool is an integral type and consider code that treats it as such as inviting bugs. We _want_ bool to be considered as being completely distinct from integer types. The fact that you can ever pass 0 or 1 to a function that accepts bool without a cast is a problem in and of itself. But it doesn't really surprise me that Walter doesn't agree on that point, since he's never agreed on that point, though I was hoping that this DIP was convincing enough, and its failure is certainly disappointing. - Jonathan M Davis The issue that I see is unintended implicit conversation when passing values to functions that have both int and bool overloads. If we have a way of indicating that implicit conversions are not allowed, when passing values to functions then the issues that the DIP brought up is resolved. - Alex
Re: DIP 1014--Hooking D's struct move semantics--Has Been Accepted
On Thursday, 8 November 2018 at 03:04:06 UTC, Jonathan M Davis wrote: On Wednesday, November 7, 2018 6:54:54 PM MST Mike Parker via Digitalmars-d- announce wrote: I'm happy to announce that Walter and Andrei have rendered their verdict on DIP 1014. They were in agreement on two points: they don't like it, but they know we need it. Given that there are no other alternative proposals and that they could see no alternative themselves, they decided to accept this DIP without modification. I think that that probably sums the situation up pretty nicely. The fact that we need something like this is just plain ugly, and if it starts getting used frequently, there's definitely a problem, but there are use cases, where it's going to be invaluable. - Jonathan M Davis This pull request is undoubtedly a major factor of Walter and Andrei approval of DIP 1014 https://github.com/dlang/druntime/pull/2310 Alex
Re: Lost in Translation: Encapsulation
On Tuesday, 6 November 2018 at 15:14:55 UTC, Mike Parker wrote: Last week, inspired by another discussion in these forums about D's private-to-the-module form of encapsulation, I spent a few hours putting a new article together for the blog. Ali, Joakim, Nicholas helped me get it in shape. The blog: https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/ Reddit: https://www.reddit.com/r/programming/comments/9up2yo/lost_in_translation_encapsulation_in_d/ You just describe how package access attribute works better then the spec itself! Good job. -Alex
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Monday, 5 November 2018 at 01:23:44 UTC, nobodycares wrote: I assume the moderator(s) doesn't like me anymore, as my posts are no longer being published. Great way to run a discussion forum by the way. It not just you, my post had disappear only to reappear on later dates. I can vouch for them by saying that this is a bug that you and I are experiencing. -Alex
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Sunday, 4 November 2018 at 15:40:03 UTC, Neia Neutuladh wrote: On Sun, 04 Nov 2018 11:36:39 +, FooledDonor wrote: Can we argue about the problems arising from the potential introduction of this feature? There are many potential features that wouldn't cause problems in isolation. Should we add all of them? Obviously not; the result would be a horribly complex language that takes too much time to learn and is impossible to maintain. No one should/need learn the entire tool itself in order to get thing done. If you found yourself in such a situation, then you seriously need to rethink on what you should be doing. -Alex
Re: Release D 2.083.0
On Friday, 2 November 2018 at 00:12:29 UTC, Martin Nowak wrote: Glad to announce D 2.083.0, ♥ to the 51 contributors. This release comes with betterC support in dub, new CppRuntime_* version identifiers, an isZeroInit trait, and an exported environment variable DUB_PACKAGE_VERSION during dub build steps. http://dlang.org/download.html http://dlang.org/changelog/2.083.0.html - -Martin I am disappointed that the bug fixes regarding alias wasn't pulled for this release.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 20:23:21 UTC, Walter Bright wrote: On 10/31/2018 6:25 AM, 12345swordy wrote: Again what consist of a module of being "too large"? That seems to me that more of a art then a science. If you're looking for a rigid rule, you won't find one. But a good indicator is if it contains more than one abstraction that has nothing particular in common with each other. Sure thing, however I wonder why "protected package" doesn't exist for classes, seems to me a missing opportunity there.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 13:24:10 UTC, Adam D. Ruppe wrote: On Wednesday, 31 October 2018 at 13:16:45 UTC, 12345swordy wrote: I seen modules with more then thousand lines of code in the Phobos library. $ wc simpledisplay.d nanovega.d dom.d cgi.d 14152 54984 443111 simpledisplay.d 15289 63707 573986 nanovega.d 7159 24473 187572 dom.d 4132 16727 128299 cgi.d This is an counter argument how?
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 13:39:25 UTC, rikki cattermole wrote: On 01/11/2018 2:35 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote: On 01/11/2018 2:25 AM, 12345swordy wrote: [...] Because it is. My rules (which tend to be a little stricter than most peoples) are: Soft split 1k LOC, hard split 3k LOC without a very good reason not to. But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split. Ok, you agree that it is subjective. Why is having more then one class per file "too large"? It doesn't. It is a group of related symbols. If it doesn't have function bodies (e.g. extern(C++) or COM) I would call that module to have too small of a scope. Why do anyone have to create a file for every class if they wanted them to be encapsulated then? Why can't we put them in the same file if they are relativity small?
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote: On 01/11/2018 2:25 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole wrote: On 01/11/2018 2:16 AM, 12345swordy wrote: [...] We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive. That's nice. Again what consist of a module of being "too large"? That seems to me that more of a art then a science. Because it is. My rules (which tend to be a little stricter than most peoples) are: Soft split 1k LOC, hard split 3k LOC without a very good reason not to. But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split. Ok, you agree that it is subjective. Why is having more then one class per file "too large"?
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole wrote: On 01/11/2018 2:16 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson wrote: Running into such problems is a sign that your module is too large, and should become a package. I seen modules with more then thousand lines of code in the Phobos library. What exactly consist a module of being "too large"? If having two classes in a module with around 200-300 lines of code "too large"? We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive. That's nice. Again what consist of a module of being "too large"? That seems to me that more of a art then a science.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson wrote: Running into such problems is a sign that your module is too large, and should become a package. I seen modules with more then thousand lines of code in the Phobos library. What exactly consist a module of being "too large"? If having two classes in a module with around 200-300 lines of code "too large"?
Re: Add D front-end, libphobos library, and D2 testsuite... to GCC
On Monday, 29 October 2018 at 09:57:46 UTC, Walter Bright wrote: On 10/28/2018 8:43 PM, Mike Parker wrote: Congratulations are in order for Iain Buclaw. His efforts have been rewarded in a big way. Last Friday, he got the greenlight to move forward with submitting his changes into GCC: Reddit: https://www.reddit.com/r/programming/comments/9sb74k/the_d_language_frontend_finally_merged_into_gcc_9/ HackerNews (at #12 on the front page): https://news.ycombinator.com/news Be prepare for the influx of newbies ;-)
Re: Copy Constructor DIP and implementation
On Monday, 24 September 2018 at 17:34:58 UTC, Manu wrote: On Mon, 24 Sep 2018 at 00:55, Gary Willoughby via Digitalmars-d-announce wrote: On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson wrote: > It appears that @implicit has been removed from the > implementation [1], but not yet from the DIP. > > https://github.com/dlang/dmd/commit/cdd8100 Good, It's not needed. @implicit is desperately needed (just not for copy constructors!). Do you have confidence that an @implicit proposal will happen if you all insist that it's removed here? This is a great driving motivator to support @implicit's introduction. If we are going to introduce the keyword/attribute implicit then it needs its own DIP. As of now, this DIP have a very weak justification for it. -Alex
Re: Copy Constructor DIP and implementation
On Monday, 17 September 2018 at 23:07:22 UTC, Manu wrote: On Mon, 17 Sep 2018 at 13:55, 12345swordy via Digitalmars-d-announce wrote: On Tuesday, 11 September 2018 at 15:08:33 UTC, RazvanN wrote: > Hello everyone, > > I have finished writing the last details of the copy > constructor DIP[1] and also I have published the first > implementation [2]. As I wrongfully made a PR for the DIP > queue in the early stages of the development of the DIP, I > want to announce this way that the DIP is ready for the > draft review now. Those who are familiar with the compiler, > please take a look at the implementation and help me improve > it! > > Thanks, > RazvanN > > [1] https://github.com/dlang/DIPs/pull/129 > [2] https://github.com/dlang/dmd/pull/8688 The only thing I object is adding yet another attribute to a already big bag of attributes. What's wrong with adding keywords? -Alexander I initially felt strongly against @implicit, it shouldn't be necessary, and we could migrate without it. But... assuming that @implicit should make an appearance anyway (it should! being able to mark implicit constructors will fill a massive usability hole in D!), then it doesn't hurt to use it eagerly here and avoid a breaking change at this time, since it will be the correct expression for the future regardless. If that where the case, then why not make it an actual keyword? A frequent complaint regarding D is that there are too many attributes, this will undoubtedly adding more to it. -Alexander
Re: automem v0.3.5 - now with more vector (like std::vector, not Physics)!
On Thursday, 20 September 2018 at 14:57:42 UTC, Atila Neves wrote: If you've never heard of automem before, I wrote it to have C++-style smart pointers in D that I could use in @nogc code: [...] Official bindings to std::vector will soon be added by manu. (I think)
Re: LLVM 7.0.0 no mention of D anymore
On Wednesday, 19 September 2018 at 13:10:07 UTC, Daniel Kozak wrote: http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html#external-open-source-projects-using-llvm-7 no mention of D anymore :( http://releases.llvm.org/6.0.0/docs/ReleaseNotes.html#external-open-source-projects-using-llvm-6 http://releases.llvm.org/5.0.0/docs/ReleaseNotes.html#external-open-source-projects-using-llvm-5 http://releases.llvm.org/4.0.0/docs/ReleaseNotes.html#external-open-source-projects-using-llvm-4-0-0 Hold your horses, it not exactly trivial for the ldc devs to update support to llvm 7 that just recently came out.
Re: fearless v0.0.1 - shared made easy (and @safe)
On Tuesday, 18 September 2018 at 17:20:26 UTC, Atila Neves wrote: The `shared` keyword currently means one of two things: 1. You can use core.atomic with it 2. It's some struct and you BYOM (Bring Your Own Mutex) [...] Why is this is an external 3rd party library isn't of the standard library? -Alexander
Re: Copy Constructor DIP and implementation
On Tuesday, 11 September 2018 at 15:08:33 UTC, RazvanN wrote: Hello everyone, I have finished writing the last details of the copy constructor DIP[1] and also I have published the first implementation [2]. As I wrongfully made a PR for the DIP queue in the early stages of the development of the DIP, I want to announce this way that the DIP is ready for the draft review now. Those who are familiar with the compiler, please take a look at the implementation and help me improve it! Thanks, RazvanN [1] https://github.com/dlang/DIPs/pull/129 [2] https://github.com/dlang/dmd/pull/8688 The only thing I object is adding yet another attribute to a already big bag of attributes. What's wrong with adding keywords? -Alexander
Re: SAoC Updates
On Tuesday, 31 July 2018 at 13:50:52 UTC, Mike Parker wrote: On Tuesday, 31 July 2018 at 13:36:13 UTC, bachmeier wrote: On Tuesday, 31 July 2018 at 03:23:41 UTC, Mike Parker wrote: Second, it is incumbent upon non-student applicants who are currently employed by a software development firm to ensure there are no contractual barriers to participating. That seems risky - an employer may claim ownership of those contributions. That's precisely why I mention it. We expect that applicants to take the necessary steps to verify there are no issues *before* applying. If, during the application process, it is discovered that there are potential issues, that's grounds for an automatic rejection. We do have access to a legal team, so there will be a certain level of due diligence where required. Would it be easier to submit a approved conflict of interest paper with the application? -Alexander
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 19:22:13 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 17:59:27 UTC, Ecstatic Coder wrote: While ANY C++ game can make ANY number of allocations/allocations inside a game loop and still run without a risking any freeze. You are doing something very wrong if you are doing this. -Alexander Just try it. For what rhyme or reason!? You shouldn't be allocating and deallocating inside a critical loop in the first place! Regardless people have shown you solutions regarding string concatenation. Are you going to address that or you just going to ignore them? -Alexander Also when I used the word phobia I was pretty sure that I was referring to irrational fear of things. Big emphasis on the word "irrational". -Aleaxander
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 17:59:27 UTC, Ecstatic Coder wrote: While ANY C++ game can make ANY number of allocations/allocations inside a game loop and still run without a risking any freeze. You are doing something very wrong if you are doing this. -Alexander Just try it. For what rhyme or reason!? You shouldn't be allocating and deallocating inside a critical loop in the first place! Regardless people have shown you solutions regarding string concatenation. Are you going to address that or you just going to ignore them? -Alexander
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 17:16:54 UTC, Ecstatic Coder wrote: Are you seriously going to ignore video games that are entirely implemented in GC focus language such as C#/java?! The GC is NOT AN ISSUE IF YOU KNOW WHAT YOU ARE DOING! -Alexander +1 You are start reminding me of another person who pull these type of stunts. Which is not a good thing btw, as that guy is a notorious troll. While ANY C++ game can make ANY number of allocations/allocations inside a game loop and still run without a risking any freeze. You are doing something very wrong if you are doing this. -Alexander
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 17:04:37 UTC, Ecstatic Coder wrote: Also if your concatenate string in a loop in c# then you use the https://www.dotnetperls.com/string-join function as it simpler and faster. There is no reason why we can't have the function equivalent in D. -Alexander Yeah I know, this code was DELIBERATLY naive. That was the whole point of it. Misuse of tools is not an argument against the tools themselves. Blaming the GC for your "naive" code, is equivalent to a carpenter blaming his hammer for his error when the hammer is in fine shape. As I said before, the GC is not an issue if you know what you are doing. -Alexander
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 17:00:49 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 16:48:17 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 16:45:41 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 16:33:19 UTC, 12345swordy wrote: [...] LOL Unless you implement your game in managed-C++, I don't think there is much to worry about that though... Your comparison is logical fallacious to begin with. -Alex I was just trying to explain why C++ developers have GC phobia through a very simple example. Even the simplest string concatenation in any garbage collected language (like Java, etc) can be the cause of of serious game freeze, which most players (including me) won't tolerate for long. Even one tiny allocation which is hidden deep somewhere in an external library of some sort... But it was obviously pointless to try to explain it on this D forum. I understand it now. Are you seriously going to ignore video games that are entirely implemented in GC focus language such as C#/java?! The GC is NOT AN ISSUE IF YOU KNOW WHAT YOU ARE DOING! -Alexander
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 14:52:46 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 14:11:05 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 13:50:37 UTC, 12345swordy wrote: [...] +1 Just one silly question. Can the following "naive" D code trigger a garbage collection stall ? score.Text = point_count.to!string() ~ " POINTS"; The correct answer is: I don't know, as I don't know what "point_count" is in the first place, as it never been defined. -Alex Actually you answer was right even if the point count was not stored as an integer ;) For C++, the answer is : never. Two small memory blocks will have to be allocated from the memory pool, which is not smart, obviously, but apart of that, nothing to worry about. Because there is no garbage collector in C++, memory has to be allocated and deallocated in a continuous manner... Also if your concatenate string in a loop in c# then you use the https://www.dotnetperls.com/string-join function as it simpler and faster. There is no reason why we can't have the function equivalent in D. -Alexander
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 16:45:41 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 16:33:19 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote: For C++, the answer is : never. ...Yeah I had already figure out what your aiming at. For C++ the correct answer is "I do not know as I don't know how it is implemented". You act like there isn't any GC libraries for C++. -Alex LOL Unless you implement your game in managed-C++, I don't think there is much to worry about that though... Your comparison is logical fallacious to begin with. -Alex
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote: For C++, the answer is : never. ...Yeah I had already figure out what your aiming at. For C++ the correct answer is "I do not know as I don't know how it is implemented". You act like there isn't any GC libraries for C++. -Alex
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 14:11:05 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 13:50:37 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote: [...] No triple AAA engine is going to switch to D for the following reasons: 1.)Cost vs benefit from converting C++ to D. 2.)Gamers do not care how things are implemented, they want results. 3.)There are high abundance of c++ programmers for employees to hired. I can't say the same thing for D. 4.)GC phobia.(The notorious culprit) -Alex +1 Just one silly question. Can the following "naive" D code trigger a garbage collection stall ? score.Text = point_count.to!string() ~ " POINTS"; The correct answer is: I don't know, as I don't know what "point_count" is in the first place, as it never been defined. -Alex
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote: LOL Ok, if I'm wrong, then this means D is already a perfect replacement to C++, especially for game development. Just by curiosity, can you tell me how many successful commercial games based on a D game engine are released each year ? Or just this year maybe... No triple AAA engine is going to switch to D for the following reasons: 1.)Cost vs benefit from converting C++ to D. 2.)Gamers do not care how things are implemented, they want results. 3.)There are high abundance of c++ programmers for employees to hired. I can't say the same thing for D. 4.)GC phobia.(The notorious culprit) -Alex
Re: The #dbugfix Campaign Round 1 Report
On Monday, 14 May 2018 at 15:23:41 UTC, Mike Parker wrote: I planned an extended vacation with my wife around DConf this year and, despite my intentions before we left, fell quite far behind on my D duties. I'm in the process of getting caught up with everything, and that includes publishing the results of the first round of the #dbugfix campaign. [...] Be sure to post it in r/programming
Re: Who says we can't call C++ constructors?
On Saturday, 21 April 2018 at 12:41:02 UTC, Atila Neves wrote:
From https://dlang.org/spec/cpp_interface.html:
"C++ constructors, copy constructors, move constructors and
destructors cannot be called directly in D code".
O RLY?
// hdr.hpp
struct Struct {
void *data;
Struct(int i);
Struct(const Struct&);
Struct(Struct&&);
~Struct();
int number() const;
};
// cpp.cpp
#include "hdr.hpp"
#include
using namespace std;
Struct::Struct(int i) {
cout << " C++: int ctor " << i << endl;
data = new int(i);
}
Struct::Struct(const Struct& other) {
cout << " C++: copy ctor " << other.number() << endl;
data = new int(*reinterpret_cast(other.data));
}
Struct::Struct(Struct&& other) {
cout << " C++: move ctor " << other.number() << endl;
data = other.data;
other.data = nullptr;
}
Struct::~Struct() {
cout << " C++ dtor " << number() << endl;
delete reinterpret_cast(data);
}
int Struct::number() const {
return data == nullptr ? 0 :
*reinterpret_cast(data);
}
// ctors.dpp
#include "hdr.hpp"
import std.stdio;
void main() {
writeln("D: int ctor");
const cs = const Struct(2);
auto ms = Struct(3);
writeln;
writeln("D: copy ctor");
auto ccs = Struct(cs); assert(ccs.number() == 2);
auto cms = Struct(ms); assert(cms.number() == 3);
writeln;
writeln("D: move ctor");
auto tmp = Struct(4);
// dpp.move causes the move ctor be called instead of
the copy ctor
auto mv1 = Struct(dpp.move(tmp)); assert(mv1.number()
== 4);
// moved from, now T.init (even if the C++ code doesn't
do that)
assert(tmp.data is null);
// This last line doesn't work with dmd due to issue
18784.
// It works fine with ldc though.
auto mv2 = Struct(Struct(5)); assert(mv2.number() == 5);
writeln;
}
% clang++ -c cpp.cpp
% d++ --compiler=ldc2 ctors.dpp cpp.o -L-lstdc++
% ./ctors
D: int ctor
C++: int ctor 2
C++: int ctor 3
D: copy ctor
C++: copy ctor 2
C++: copy ctor 3
D: move ctor
C++: int ctor 4
C++: move ctor 4
C++ dtor 0
C++: int ctor 5
C++: move ctor 5
C++ dtor 0
C++ dtor 5
C++ dtor 4
C++ dtor 0
C++ dtor 3
C++ dtor 2
C++ dtor 3
C++ dtor 2
Atila
You are a mad man!
Re: std.variant Is Everything Cool About D
On Thursday, 29 March 2018 at 14:10:39 UTC, Mike Parker wrote: Jared Hanson (a.k.a Meta and MetaLang around these parts) was inspired by an article titled "std::visit is everything wrong with modern C++" to contrast it with D's std.variant.visit. The result is this well-written post for the D Blog. The blog: https://dlang.org/blog/2018/03/29/std-variant-is-everything-cool-about-d/ Reddit: https://www.reddit.com/r/programming/comments/881hmi/stdvariant_is_everything_cool_about_d/ There are some quite criticisms being made in the comments section.
Re: State of D 2018 Survey
On Wednesday, 28 February 2018 at 13:41:56 UTC, Mike Parker wrote: About a month ago, Sebastian Wilzbach sent an email out to a few of the core D folks asking for feedback on a survey he had put together. He thought it would be useful for the Foundation to use in order to make decisions about where to expend development efforts. Eventually Andrei gave his stamp of approval, the survey questions were tweaked, and then it was ready to roll. Of course I would love for you to read my blog post announcing it, but if you want to skip the prose and go straight to the good stuff, here's the survey link: https://seb134.typeform.com/to/H1GTak The blog: https://dlang.org/blog/2018/02/28/the-state-of-d-2018-survey/ Reddit: https://www.reddit.com/r/d_language/comments/80w29n/the_state_of_d_2018_survey/ Submitted, though I think it's a good idea to create a library that take advantage of the GC. I am hype for the ability to implement your own custom Garbage collector.
Re: D as a Better C
On Wednesday, 23 August 2017 at 13:12:04 UTC, Mike Parker wrote: To coincide with the improvements to -betterC in the upcoming DMD 2.076, Walter has published a new article on the D blog about what it is and why to use it. A fun read. And I'm personally happy to see the love this feature is getting. I have a project I'd like to use it with if I can ever make the time for it! The blog: https://dlang.org/blog/2017/08/23/d-as-a-better-c/ Reddit: https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/ Questions regarding c++ classes in betterC mode. Can the c++ class destructor be called by the destroy function or do I have to call it explicitly like p-<~class()? Alex
Re: Visual D 0.45 released - better VS2017 integration
On Thursday, 3 August 2017 at 07:04:55 UTC, Rainer Schuetze wrote: Hi, there is a new version 0.45 of Visual D available at http://rainers.github.io/visuald/visuald/StartPage.html Most changes are bug fixes and incremental improvements, maybe standing out: * improved VS 2017 integration * task list support * dparser update to recent language additions See http://rainers.github.io/visuald/visuald/VersionHistory.html for the full version history. Visual D is a Visual Studio extension that adds D language support to VS2008-2017. It is written in D, its source code can be found on github: https://github.com/D-Programming-Language/visuald, pull requests welcome. Rainer Much appreciated for your efforts. Alex.
