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: dual-context deprecation
On Monday, 17 May 2021 at 14:35:51 UTC, Steven Schveighoffer
wrote:
On 5/17/21 9:47 AM, jmh530 wrote:
The code below (simplified from my actual problem) generates a
warning that member function b "requires a dual-context, which
is deprecated".
However when I look at the list of deprecated features [1],
I'm not seeing which one this is referring to. Is it a valid
deprecation?
I could only find this [2] reference to dual-contexts, which
suggests that the problem relates to passing aliases into
member functions. Moving it to a member function fixes the
problem. Alternately, I could make the alias part of Foo's
type. My use case it is just a little easier structured like
this, but I get that there are workarounds.
My bigger question is about why it isn't listed more than
anything. I.e., should I file something in bugzilla.
```d
struct Foo
{
double a;
this(double x)
{
this.a = x;
}
double b(alias inverse)()
{
return inverse(a);
}
}
void main()
{
auto foo = Foo(2.0);
auto x = foo.b!(a => (10.0 ^^ a))();
}
```
The feature is deprecated in its current form. The issue as I
understand it (i.e. very little) is that compilers other than
DMD could not use this same way to implement dual contexts, and
so they could not have the feature. This means that valid code
in DMD would not compile on GDC or LDC.
The way forward was to deprecate the mechanism used to
implement it for DMD, and at some point tackle it in a
backend-agnostic way.
Personally, I don't know why we can't fix it so that it's
portable, but I understand so little about compilers that I've
pretty much stayed out of it. The feature is very much needed.
-Steve
The dual context that warning is referring to is vthis2, which
the gdc maintainer struggle to implemented for the gdc compiler.
A correct fix involves templates having their own context.
-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: How does D's templated functions implementation differ from generics in C#/Java?
On Friday, 7 August 2020 at 21:03:47 UTC, aberba wrote: Syntactically they look the same (although D's can do more things) so I'm trying to understand how why in D it's called template but in languages like C#/Java they're generics. I guess I have fair understanding of D's code generation but isn't it same as what what is available in those languages too? How are the implementation different? I think this is relevent: https://github.com/dotnet/csharplang/issues/110
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: What is the current stage of @property ?
On Wednesday, 10 June 2020 at 22:30:37 UTC, Vinod K Chandran wrote: On Wednesday, 10 June 2020 at 22:15:25 UTC, 12345swordy wrote: It can't do binary operations and unary operations. @12345swordy, You mean we can't do such ops inside the property ? No, it means you can't do this: e.x += 123;
Re: What is the current stage of @property ?
On Wednesday, 10 June 2020 at 21:40:44 UTC, Paul Backus wrote:
On Wednesday, 10 June 2020 at 20:24:19 UTC, Vinod K Chandran
wrote:
Hi all,
I read in an old thread that authors of D wants to eliminate
@property. I just roughly read the big thread bu couldn't find
a conclusion. After all that thread is a 48 page longer jumbo
thread. So out of curiosity, i am asking this. What is the
current state of @property ? Is it deprecated ?
The current state of @property is that it doesn't really do
anything. D allows you to call functions without parentheses,
and to use assignment syntax to call a single-argument
function, so you can write getters and setters that work like
properties even if you don't use the @property annotation:
struct Example
{
private int x_;
int x() { return x; } // getter
void x(int n) { x = n; } // setter
}
void main()
{
Example e;
e.x = 123; // calls setter
int y = e.x; // calls getter
}
It can't do binary operations and unary operations.
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: Pattern matching via switch?
On Sunday, 15 March 2020 at 17:55:59 UTC, Steven Schveighoffer wrote: On 3/14/20 3:04 PM, 12345swordy wrote: I.E. switch (object) case Type1 t1: case Type2 t2: case Type3 t3: Is this a class object and you are trying to determine at runtime which derived type it is and perform an action based on that? Or are you trying to switch on the type of a concrete item? It should technically be possible to use the fully qualified name to switch on, but I don't think typeid(Type1).name is usable as a switch label. -Steve https://docs.microsoft.com/en-us/dotnet/csharp/pattern-matching It is an example from c#. object is the top type in that language. https://en.wikipedia.org/wiki/Top_type
Re: Pattern matching via switch?
On Saturday, 14 March 2020 at 20:52:30 UTC, aliak wrote: On Saturday, 14 March 2020 at 19:04:28 UTC, 12345swordy wrote: [...] You can use the sumtype package (https://code.dlang.org/packages/sumtype): [...] That simply to much verbiage.
Pattern matching via switch?
I.E. switch (object) case Type1 t1: case Type2 t2: case Type3 t3:
Re: @property with opCall
On Monday, 9 March 2020 at 12:14:06 UTC, Adam D. Ruppe wrote: On Monday, 9 March 2020 at 10:09:56 UTC, Calvin P wrote: @property exists so many years, Druntime & Phobos use it 2280 times. I can't believe it is not recommended. They never implemented it right. This opCall type thing was THE case we brought up to introduce @property in the first place but it never actually affected this. For years, @property did absolutely nothing. We were told to use it for the future. Some people tried to put on a compiler switch to make it do something, but they consistently made that switch do the wrong thing! Then @property got frozen for fear of broken changes. LOL. Now @property changes the result of `typeof(a.prop)`... but nothing else. @property is one of the biggest WTFs of D's development. no kidding, d should just copy c# property semantics as the current implementation of it is wonky. Mike attempted to add binary operations to it, but instead close his dip pull request and the following dmd pull requested. -Alex
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: Why does nobody seem to think that `null` is a serious problem in D?
On Friday, 30 November 2018 at 15:32:55 UTC, 12345swordy wrote: On Friday, 30 November 2018 at 12:00:46 UTC, Atila Neves wrote: On Thursday, 29 November 2018 at 18:31:41 UTC, SimonN wrote: On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez Hermoso wrote: [...] [...] 100 % agree that there should be non-nullable class references, they're my main missing feature in D. Likewise, I'm astonished that only few D users wish for them. https://github.com/aliak00/optional/blob/master/source/optional/notnull.d "But I don't like the verbosity!" alias MyClass = NotNullable!MyClassImpl; Huh neat, though it would nice to allow conversion of Nullable to NotNullable via runtime conditional checking. NotNullable!MyClassImpl = (MyClassImpvar != Null) ? MyClassImpvar : new MyClassImpvar(); I meant new MyClassImp(), but you get the idea.
Re: Why does nobody seem to think that `null` is a serious problem in D?
On Friday, 30 November 2018 at 12:00:46 UTC, Atila Neves wrote: On Thursday, 29 November 2018 at 18:31:41 UTC, SimonN wrote: On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez Hermoso wrote: When I was first playing with D, I managed to create a segfault What's the reasoning for allowing this? 100 % agree that there should be non-nullable class references, they're my main missing feature in D. Likewise, I'm astonished that only few D users wish for them. https://github.com/aliak00/optional/blob/master/source/optional/notnull.d "But I don't like the verbosity!" alias MyClass = NotNullable!MyClassImpl; Huh neat, though it would nice to allow conversion of Nullable to NotNullable via runtime conditional checking. NotNullable!MyClassImpl = (MyClassImpvar != Null) ? MyClassImpvar : new MyClassImpvar();
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: struggling to link against a C global in D (win/vs2017)
On Monday, 29 October 2018 at 00:16:38 UTC, Stanislav Blinov
wrote:
On Monday, 29 October 2018 at 00:01:21 UTC, DanielG wrote:
In my D app I'm declaring it this way:
extern (C) {
extern __gshared int myIntValue;
int myIntFunc (int a, int b);
}
The function seems to link OK, but the C global will not.
Should it be extern(Windows), perchance?.. (I haven't D on
Windows for ages).
Nope, you use export.
Re: We need an internal keyword.
On Monday, 22 October 2018 at 11:06:42 UTC, Jonathan M Davis wrote: On Monday, October 22, 2018 2:30:21 AM MDT Basile B. via Digitalmars-d wrote: On Monday, 22 October 2018 at 08:25:17 UTC, Andrea Fontana wrote: > Moreover: you're the author of the module so you're supposed > to know how it works and which members you should call or > not. - team - maintainer of a module written by someone that works elsewhere now. that's two cases where strict privacy can be optionally a thing avoiding wrong usage of private members within the scope of a module. Part of the point is that if the module is large enough that the folks working on the code can't actually keep track of what's in it, then it's too large, and as such, if you need to protect your class or struct members from the rest of the module, then it really should be in a separate module for the code to be properly maintainable anyway. Yes, having multiple people involved makes the problem worse (especially when some of them join the team later), but it doesn't fundamentally change the issue. If it changes anything, it simply makes the argument stronger for preferring smaller modules so that they're easier to digest. Personally, I've found that larger modules have worked just fine for me without having to worry about these sort of encapsulation issues. It simply isn't a problem, and I don't recall ever seeing a bug because of it. But anyone who's worried about it always has the option of simply going for smaller modules, and the encapsulation problem is already solved without making the language any more complicated. Plenty of folks already think that it's best practice te prefer relatively small modules anyway, and if you need a way to protect your private member variables from the module when the module isn't large, then you're definitely doing something wrong. Given the D philosophy that the module is the primary unit of encapsulation and that you should at least roughly understand the entire module when working on it (or it's almost certainly too large), having an access level to protect member variables from the rest of the module simply makes no sense. Anyone who feels the need for such an access level think about what they're doing with their code and why they feel the need for it - whether it's simply because they're used to it from other languages, or because they're organizing their code in a manner which is detrimental to maintainability. - Jonathan M Davis Here is the intial dip draft: https://github.com/12345swordy/DIPs/tree/Encapsulation If Walter Bright insist that the module is the unit of encapsulation then I propose we get rid of the "one module per file" restriction, by introducing sub modules. -Alex
Re: We need an internal keyword.
On Sunday, 21 October 2018 at 21:48:22 UTC, Laurent Tréguier wrote: On Sunday, 21 October 2018 at 17:09:05 UTC, 12345swordy wrote: [...] It's not "my" solution. It's D's solution. I perfectly understand why you'd want this and I would probably make use of a private/internal difference myself if it was available. If you already know about this solution however, I don't even know why you're starting this thread; since changing the behavior of private would be a major language change breaking tons of existing codebases, plus it would require adding yet another keyword. Given that this conversation has happened before and things haven't changed, I'm very doubtful that it could happen at any point in time, sadly. If the cost out way the benefits then I simply introduce the "strict" keyword to avoid code breakage, or introduce the optional module scoping. -Alex
Re: We need an internal keyword.
On Sunday, 21 October 2018 at 19:53:35 UTC, Jonathan M Davis
wrote:
On Saturday, October 20, 2018 9:17:23 PM MDT 12345swordy via
Digitalmars-d wrote:
So that classes can share some of their variables but not
others in a module.
IE.
class A
{
internal int A; //This is shared in the module
private int B; // But not this.
}
No need to reintroduce the "Friend" feature from cpp.
Well, if you feel strongly enough about it, you can always
create a DIP to try to change things, but I think that I can
quite safely say that you have pretty much no chance of it
getting accepted. Walter has been quite clear on this topic
when it has been discussed previously (and there was a major
discussion on it not very long ago). It is very much on purpose
that access is controlled at the module level, and if your
module is large enough that it is actually causing problems for
a class or struct to not be able to disallow access of its
members to other symbols in the module, then the module is too
large, and the class should be put in a separate module. We
already have full control of who can access the members of a
class or struct by controlling which module or package its in
and what else is in that module or package with it. If you want
greater control without splitting up your modules more (at
least as far as importing goes), you can always take advantage
of public imports to split the code itself into more modules
while making it possible to get all of the symbols with a
single import statement.
Certainly, if we had internal or friend or other mechanisms for
more fine-grained control without doing it at the module-level,
it would eliminate the need to put code into separate modules
in some cases, but it would also complicate the language, and
what we have works quite well in general.
If you don't like the fact that member access is done at the
module level, then I'm sorry, but overall, this really seems to
be a philosphical complaint and not a practical one, and Walter
has made his stance on it very clear. Based on what he's said
previously, you would need very strong, practical arguments for
why it's causing actual bugs in programs and why the current
approach is not cutting it to stand any chance of convincing
Walter. And honestly, I have never seen anyone come up with an
argument that was particularly good in that regard. It mostly
seems to come down to folks simply objecting to the idea that
anything inside a module would have access to a class' private
members rather than that it's actually caused bugs. In
practice, it's usually either actually useful, or it doesn't
matter.
Either way, simply making post stating that you think that we
should have the feature isn't going to get you anywhere. If you
want it, you'll need to find a way to convince Walter.
- Jonathan M Davis
I do plan to write a DIP on this, no question about it. However
walter have been shown to change his mind unexpectedly. (Remember
the "mangle symbol only" discussion that manu had argue in favor
of, which we all thought he sternly opposed to, only to changed
his mind at the last minute, when a pull request shown up?)
Yes I am aware of the previous discussion regarding this. How can
I forget about it as that guy who complain about it resort to
imposter other people including me.
https://forum.dlang.org/thread/vpxoidaqfbfrnnsep...@forum.dlang.org?page=1
However that guy didn't property explain why this was an issue.
The issue is encapsulation and the traditional get and set
functions for security checking and value checking, etc, before
setting the value, retrieving the value and after setting the
value. Programmers such my self sometimes find it easier to
maintain classes if they are put in the same file, rather than in
each own file.
The "package" solution brought up by another user risk the
possibility of making things more complicated and harder to
maintain than it should be, when working with code that is
considerably small spread across multiple files.
I have two solutions in mind:
A.)Introduce the keyword "strict" for the other keywords private
and protected only class and structs to prevent being accessed
from outside the class in the same module by accident.
Example:
class A
{
strict private int x;// This can't be shared in module
strict protected int y; //ditto
private int x; //This can be shared in module
protected int y; //ditto
}
B.)Get rid of the "one module per file" restriction by
introducing optional module scoping to allow multiple modules in
a file to allow easy package creation for code that is consider
to be small without having to maintain multiple files.
Module C;
Module A // Module A in the C package
{
}
module B // AKA B.A
{
}
-Alex
Re: shared - i need it to be useful
On Sunday, 21 October 2018 at 18:45:15 UTC, Walter Bright wrote: I'd like to add that if the compiler can prove that a T* points to a unique T, then it can be implicitly cast to shared(T)*. And it does so, like the result of .dup can be so converted. This can be achieved by using the unique struct and enforce the uniqueness at compile time. https://github.com/dlang/phobos/blob/master/std/typecons.d#L130
Re: We need an internal keyword.
On Sunday, 21 October 2018 at 08:40:36 UTC, Laurent Tréguier
wrote:
On Sunday, 21 October 2018 at 03:17:23 UTC, 12345swordy wrote:
So that classes can share some of their variables but not
others in a module.
IE.
class A
{
internal int A; //This is shared in the module
private int B; // But not this.
}
No need to reintroduce the "Friend" feature from cpp.
This is by design; the D way of dealing with this would be to
split the module into a package with multiple modules. The A
class would be in its own module, and use `package` where you
used `internal` so that other modules in the same package can
have access to it.
Using a package.d package module
(https://dlang.org/spec/module.html#package-module), you can
still use the multiple modules just as if they were a single
module.
Instead of a source tree like this:
source
|
+-some
|
+-thing.d
You'd end up with a source tree like this:
source
|
+-some
|
+-thing
|
+-package.d
|
+-a.d
|
+-rest_of_the_stuff.d
Where package.d publicly imports a.d and rest_of_the_stuff.d,
so `import some.thing` would still work.
I know what the current design is!! You have zero tools in
regarding to allowing class to share certain variables but not
others in the same module! Create a module for every class is
taking all or nothing approach, when there is a reasonable middle
ground.
Your package solution just make things more unnecessarily
complicated then warranted
We need an internal keyword.
So that classes can share some of their variables but not others
in a module.
IE.
class A
{
internal int A; //This is shared in the module
private int B; // But not this.
}
No need to reintroduce the "Friend" feature from cpp.
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Saturday, 20 October 2018 at 16:37:07 UTC, Atila Neves wrote: On Saturday, 20 October 2018 at 10:28:47 UTC, Gregor Mückl wrote: [...] It turns out that translating C++ is *hard*. Partly because the language is huge and complicated, but also partly because libclang isn't all it's cracked up to be. But... dpp is probably a few full work days away from being to #include . Hopefully with the translation actually working. [...] There this pull request https://github.com/dlang/dmd/pull/8787 but apparently Manu is burn out from working on it.
Re: You don't like GC? Do you?
On Monday, 15 October 2018 at 20:22:54 UTC, Stanislav Blinov wrote: Neither are of any particular use. Pot called, he wants to see Mr. kettle.
Re: shared - i need it to be useful
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote: If you write a lock-free queue for instance, and all the methods are `shared` (ie, threadsafe), then under the current rules, you can't interact with the object when it's not shared, and that's fairly useless. Unless the compiler can show that it is ok to implicit/explicity convert the object to share without any unintended consequences. It should reject it. It seems that the better solution would to implement a implicit/explict covertion system similar to c# conversion Operators https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/statements-expressions-operators/using-conversion-operators But that itself requires an DIP itself. -Alex
Re: You don't like GC? Do you?
On Monday, 15 October 2018 at 19:57:59 UTC, Stanislav Blinov wrote: If you want to have an argument, I suggest you stop quote mining and start paying attention. If you wanted an argument from me, then you need to stop with the "LOL YOU MAD BRO" rhetoric.
Re: You don't like GC? Do you?
On Monday, 15 October 2018 at 17:30:28 UTC, Stanislav Blinov wrote: On Monday, 15 October 2018 at 16:46:45 UTC, 12345swordy wrote: On Monday, 15 October 2018 at 00:02:31 UTC, Stanislav Blinov wrote: I'm arrogants, huh? When you say statements like this. you don't give a flying duck about your impact on the industry. It come across as condescending and arrogant. Yep, and everything else that's inconvenient you'd just cut out. You mean the part that you straw man me, and resort to personal attacks? No need for me to address it. Did I hit a nerve?.. Case in point.
Re: You don't like GC? Do you?
On Monday, 15 October 2018 at 00:02:31 UTC, Stanislav Blinov wrote: I'm arrogants, huh? When you say statements like this. you don't give a flying duck about your impact on the industry. It come across as condescending and arrogant.
Re: You don't like GC? Do you?
On Sunday, 14 October 2018 at 07:51:09 UTC, Stanislav Blinov wrote: On Saturday, 13 October 2018 at 21:44:45 UTC, 12345swordy wrote: Not everyone have the time nor skills of doing manual memory management. Even more so when correctness is way more important than speed. Not everything needs to be fast. That's a lamest excuse if I ever seen one. It not an excuse, it's reality. The d language have multiple issues, the idea to have the language to have built in support for GC is NOT one of them. We develop our software using C# and the GC is a huge time saver for us as we are developing web apps. I find your side remarks to be very arrogant and condescending.
Re: You don't like GC? Do you?
On Saturday, 13 October 2018 at 14:43:22 UTC, Stanislav Blinov wrote: On Saturday, 13 October 2018 at 13:17:41 UTC, Atila Neves wrote: [...] It rarely does indeed. Usually it's someone else that has to sift through your code and fix your bugs years later. Because by that time you're long gone on another job, happily writing more code without thinking about it. [...] Not everyone have the time nor skills of doing manual memory management. Even more so when correctness is way more important than speed. Not everything needs to be fast.
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: Tuple DIP
On Wednesday, 19 September 2018 at 21:48:40 UTC, Timon Gehr wrote: On 19.09.2018 23:14, 12345swordy wrote: On Tuesday, 3 July 2018 at 16:11:05 UTC, 12345swordy wrote: On Thursday, 28 June 2018 at 13:24:11 UTC, Timon Gehr wrote: [...] Is there any way we can help on this? *Bump* I want this. So do I, but I need to get a quiet weekend or so to finish this. I am very tempted to start my own dip on this and finish it. Here's the current state of my implementation in DMD: https://github.com/dlang/dmd/compare/master...tgehr:tuple-syntax It has no tests yet, but basically, with those changes, you can write tuple literals `(1, 2.0, "3")`, you can unpack tuples using `auto (a, b) = t;` or `(int a, string b) = t;`, and tuples can be expanded using alias this on function calls, so you can now write things like `zip([1,2,3],[4,5,6]).map!((a,b)=>a+b)`. The implementation is still missing built-in syntax for tuple types, tuple assignments, and tuple unpacking within function argument lists and foreach loops. I was referring to the DIP. I am not familiar with the dmd compiler itself to create an implementation. Regardless I think you should finish you DIP and submit it as the process is going to take a very long time.
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: Tuple DIP
On Tuesday, 3 July 2018 at 16:11:05 UTC, 12345swordy wrote: On Thursday, 28 June 2018 at 13:24:11 UTC, Timon Gehr wrote: On 26.06.2018 11:55, Francesco Mecca wrote: On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote: As promised [1], I have started setting up a DIP to improve tuple ergonomics in D: [...] What is the status of the DIP? Is it ready to be proposed and dicussed? I still need to incorporate all the feedback from this thread. Also, I have started an implementation, and ideally I'd like to have it finished by the time the DIP is discussed. Unfortunately I am rather busy with work at the moment. Is there any way we can help on this? *Bump* I want this. I am very tempted to start my own dip on this and finish it.
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: extern(C++, ns) is wrong
On Friday, 14 September 2018 at 13:10:07 UTC, Atila Neves wrote: On Friday, 14 September 2018 at 09:56:52 UTC, Zot wrote: [...] I'm also completely in favour of what Manu is saying. The current situation works for no one. I very much doubt that any D programmer exists that wants what extern(C++) currently does. Yes, C++ namespaces are a mess. Who cares? We have modules. All we want is to be able to link. Walter pointed out workarounds, but: they're solutions to a problem that shouldn't exist; are ugly as sin; aren't even sufficient for manually writing bindings in the way the author intends. Forum chatter won't do it though, we need a DIP. Someone is already on it. https://github.com/look-at-me/DIPs/blob/please-for-the-love-of-all-things-good-and-holy-fix-cpp-mangling-please-ok-sorry/DIPs/DIPxCPP.md
Re: Random thought: Alternative stuct
On Tuesday, 4 September 2018 at 04:03:19 UTC, Mike Franklin wrote: In my opinion, we shouldn't add a third option. Rather, we should deprecate classes, and make and expand the capabilities of structs. If D deprecate classes, then I will stop using D entirely. I was initially drawn by D for a "better-C++" and that includes classes. -Alex
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Monday, 27 August 2018 at 18:20:04 UTC, Chris wrote: Then the D Foundation should work on it. Easier said then done. You can't go around demanding people to build factories without addressing the issues that comes with building factories, such as the big question of how is it going to be payed to be built. -Alex
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Monday, 27 August 2018 at 16:32:15 UTC, Joakim wrote: On Monday, 27 August 2018 at 16:15:37 UTC, 12345swordy wrote: On Monday, 27 August 2018 at 14:26:08 UTC, Chris wrote: On Monday, 27 August 2018 at 13:48:42 UTC, 12345swordy wrote: On Monday, 27 August 2018 at 09:36:43 UTC, Chris wrote: [...] Who's going to pay for the factory? -Alex That's for the D Foundation to figure out. There's a reason we have a D Foundation now, isn't there? The annual monthly budget is around 4K$. https://opencollective.com/dlang# -Alex "annual monthly?" Look again: https://wiki.dlang.org/Vision/2018H1#H2_2017_Review I merely using the value that the open collective site have give me. Regardless $1605 far from enough money to hire full time workers, as chris has suggested. -Alex
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Monday, 27 August 2018 at 14:26:08 UTC, Chris wrote: On Monday, 27 August 2018 at 13:48:42 UTC, 12345swordy wrote: On Monday, 27 August 2018 at 09:36:43 UTC, Chris wrote: On Monday, 27 August 2018 at 01:15:49 UTC, Laeeth Isharc wrote: [...] I think D has reached the point where that'd make perfect sense. Move from the garage to a proper factory :) Who's going to pay for the factory? -Alex That's for the D Foundation to figure out. There's a reason we have a D Foundation now, isn't there? The annual monthly budget is around 4K$. https://opencollective.com/dlang# -Alex
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Monday, 27 August 2018 at 09:36:43 UTC, Chris wrote: On Monday, 27 August 2018 at 01:15:49 UTC, Laeeth Isharc wrote: [...] I think D has reached the point where that'd make perfect sense. Move from the garage to a proper factory :) Who's going to pay for the factory? -Alex
Re: Is @safe still a work-in-progress?
On Friday, 17 August 2018 at 15:27:22 UTC, Mike Franklin wrote: I actually started writing a DIP for this about a year ago, but I need to pick my battles. Mike Is it on github? Alex
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": [...] How does this DIP interact with constructors and deconstructors as they are glorified void functions? -Alexander
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Monday, 6 August 2018 at 04:53:05 UTC, Manu wrote: If we produce a DIP to fix this, will you reject it in principle? I think you and Walter Bright made good points and I think a creation of a DIP that addresses his concerns would be a best course of action IMO. -Alexander
Re: Is it possible to deinitialize the class without calling the gc?
On Saturday, 4 August 2018 at 04:51:55 UTC, Adam D. Ruppe wrote: On Saturday, 4 August 2018 at 02:21:48 UTC, 12345swordy wrote: Which is converted to void type when passing the object to rt_finalize, which causes to lost all type information. It still has run-time type information, but indeed, the compile time info is lost. Child classes have independent destructors which do not need to adhere to the attributes of the parent class destructor, Why is this an issue? Simply don't call them. Then the object isn't fully destroyed I know the risks behind it, @nogc and others only care that non-@nogc functions are not called. That's why I propose destructor_hook function for clear transparency. So, even with the changes I outlined above, @nogc destroy would be valid if and only if it is passed a class whose *static* type explicitly includes the @nogc guarantee, which is only allowed if all the parent chains, all the way up, have either trivial destructors or their own @nogc guarantees. I was thinking along of lines of "Canary in a coal mine" when it comes to class static typing if the compiler couldn't determine the child classes that are currently inheriting the current non-final class. A system attribute "Canary" Boolean value can be override by compiler to set it to false if it detects a "Gas leak". But you can derive the bits you need from compile time info if the child destructors were restricted as described above. Unless I'm missing something too You want me to introduce the "restrict" keyword in my dip for maximum safety? Fine, I don't mind. of course you could just do the sane thing and pretend @nogc doesn't exist. then this stuff becomes a lot easier and you can just get back to work. People are treating classes like a neglected child due to the lack of @nogc. We could solve the "is it @nogc?" issue by having the compiler provide a strict readonly body of the function/class/module (after all the meta-programming has been applied obviously) and statically analyze it, but there are fears that this will lead to AST, and I don't have enough spare time to argue all day on this atm. -Alexander
Re: Is it possible to deinitialize the class without calling the gc?
On Saturday, 4 August 2018 at 02:21:48 UTC, 12345swordy wrote: Are you telling me that D is incapable of determining the classes that is currently inheriting the parent class? That not *Create a list of child classes that is currently inheriting the parent class. -Alexander
Re: Is it possible to deinitialize the class without calling the gc?
On Friday, 3 August 2018 at 21:44:55 UTC, Adam D. Ruppe wrote: Is it possible to deinitialize the class without calling the gc? Yes, use the .destroy function, Which is converted to void type when passing the object to rt_finalize, which causes to lost all type information. How is this a better solution!? Child classes have independent destructors which do not need to adhere to the attributes of the parent class destructor, Why is this an issue? Simply don't call them. There is no reason for a child class to adhere to the attribute of an empty destructor. If you want to be transparent of the possibility of them not being called, then create "destructor_hook". and moreover this cannot be detected at compile time when the attributes are processed Are you telling me that D is incapable of determining the classes that is currently inheriting the parent class? That not even extern (D) can provide information to the compiler!? Do I need to add meta information section to my DIP? I am not interested in a poor man solution here. This is a serious problem that needs addressing. I literally see the usage of __.dtor in the standard library! What's worst is that I seen sledge hammer approach to this by forcing the destroy function to be @nogc! I am not convinced that the upcoming protoObject is going to fix this issue given that old Object still exist.
Re: Is it possible to deinitialize the class without calling the gc?
On Friday, 3 August 2018 at 18:52:13 UTC, Adam D. Ruppe wrote: OK, so you don't like it... because of its name? Did you even bother reading the links that I posted? The term Finalize is commonly associated with OOP languages such as java and C#, while the term destructor is associated with C++. D has both of them. There has been some talks about splitting them. It doesn't actually call any GC functions, it just loops through destructors and calls them all. Then you should know where the implementation of finalize is located at, or am I looking at the wrong code here?
Re: Is it possible to deinitialize the class without calling the gc?
On Friday, 3 August 2018 at 16:30:41 UTC, Adam D. Ruppe wrote: rt_finalize is not the GC. Yes it is. That why is called finalize. https://en.wikipedia.org/wiki/Finalizer https://github.com/dlang/druntime/blob/633976f1b2619974e8b3b415e0052b38d1a8e2fb/src/gc/impl/manual/gc.d -Alex
Re: Is it possible to deinitialize the class without calling the gc?
On Friday, 3 August 2018 at 15:41:13 UTC, Adam D. Ruppe wrote: On Friday, 3 August 2018 at 15:32:54 UTC, 12345swordy wrote: Is there RecusiveDestruct function that can be called that is attribute friendly? No, the destructor definition in the language is not attribute friendly. Best you can do is `.destroy(obj)` and it can't see all the @nogc stuff (because the language doesn't actually support it here) Your calling the gc if you call the destroy function for classes as it calls the rt_finalize function. Regardless you didn't answer the question that I posted in the title. Alexander
Is it possible to deinitialize the class without calling the gc?
Call me curious, but I have never anyone done this before. I don't mean calling the .__dtor function as you can't call its parent .__dtor function. Is there RecusiveDestruct function that can be called that is attribute friendly? -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: Generated opAssign in the presence of a copy constructor
On Thursday, 26 July 2018 at 09:40:03 UTC, RazvanN wrote: Hello everyone! As you probably know, I am working on the copy constructor DIP and implementation. So far, I managed to implement 95% of the copy constructor logic (as stated in the DIP). The point that is a bit of a headache is how/when should opAssign be generated when a copy constructor is defined. Now here is what I have (big thanks to Andrei for all the ideas, suggestions and brainstorms): [...] Why are you not using the destroy() function? -Alexander
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Wednesday, 25 July 2018 at 19:55:50 UTC, Paolo Invernizzi wrote: I don't know what vocabulary you are used to consult, ad hominem attacks is not an argument Actually, by definition, every bug is made by a programmer that THINK to know what he is doing... no? Avoiding burden of proof by shifting goal post. Aren't you. going a little too far in judging? loaded question An so? He has explain the point in detail, go back and read his post. It's not a false equivalence fallacy: all the discussion is about IMPLICIT conversion or rvalues to lvalues. Yes it is, the issues regarding rvalue/lvalue conversion is not the same issues regarding the unsigned/signed conversion. Alexander
Re: trait to get the body code of a function?
On Wednesday, 25 July 2018 at 19:05:08 UTC, Guillaume Lathoud wrote: On Wednesday, 25 July 2018 at 04:46:20 UTC, rikki cattermole wrote: On 25/07/2018 5:32 AM, Guillaume Lathoud wrote: Thanks for all the answers. I've just had a look at an alternative: using dmd as a package. However that's a lot of doc to browse... Maybe someone has experience with dmd as a package? Not a solution. Leaks memory, not reusable and in general not very friendly to work with. Thanks. Please submit a bug report to Bugzilla on this, as I am also interest in this. Alexander
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Wednesday, 25 July 2018 at 16:43:38 UTC, Paolo Invernizzi wrote: That's an opinion, naturally. No I am expressing an argument not an opinion. "let's force the programmer to think about what he is doing, passing an rvalue by ref" Nonsense, you have shown no evidence that they don't know what they are doing when making a automatic conversion. You might as well argue against the existence of var. At best, is "let's catch early some bugs (caused by other problems as Manu pointed out)". He also pointed it is own class of problems, as it can be replicated without ref. Set of problems as automatic promotion or conversion, as decades of problems with unsigned/signed have proved... False Equivalence. We are not discussing numeric overflows here. There's not a magic conversion between apples and oranges in a foreach loop... ref value apart. https://dlang.org/spec/type.html#usual-arithmetic-conversions You where saying? -Alexander
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Wednesday, 25 July 2018 at 12:40:16 UTC, Paolo Invernizzi wrote: That proposal is a 'Syntactic Sugar' feature, that simply hide what normally need to be explicitly coded: proved a temp rvalue, pass it to a callable taking ref. What you call 'simplification', I call it 'obfuscation'; what you call uniformity I call trying to spread a well justified restriction... /Paolo A restriction which causes pointless redundant code for the caller who doesn't always have source code access. If my old teacher assistant taught me anything it is this: Redundant code is bad. You are literately forcing the programmer to create tmp variables that risk the possibility of being shadowed or worse, having its value change. Your manual solution suggestion have it own set of problems. You might as well argue against the foreach statement, because its "obfuscation". -Alexander
Re: Will the PhotoObject DIP depercated the old Object class?
On Tuesday, 24 July 2018 at 21:50:10 UTC, Jonathan M Davis wrote: On Tuesday, July 24, 2018 20:25:33 12345swordy via Digitalmars-d wrote: I am asking this, because if true then the DIP that I am currently working on has been render obsolete as I have taken the old Object class into account when writing this. It is not the plan to deprecate Object (nice as that would be), but if you're writing a DIP that specifically targets Object, then you may want to rethink it. It will continue to exist, but it's likely that its use will be discouraged, and regardless, whatever you're proposing will have to take into account that many classes will have nothing to do with Object (though that's actually already possible thanks to extern(C++)). - Jonathan M Davis This is the DIP that I am working on: https://github.com/dlang/DIPs/pull/120 It involves attributes regarding the ~this() function. ProtoObject have been suggested a solution to this. Though as you said, not many class will be guarantee to have object or ProtoObject involved. I view my DIP as a simple type checker for destroy while I think that the ProtoObject as a type enforcer for classes. -Alexander
