[Issue 19037] Nullable should use moveEmplace to support any type.
https://issues.dlang.org/show_bug.cgi?id=19037 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/c1431b133bb26d3a777bdea0815c7212d1ff09d7 Use move/moveEmplace in Nullable Fixes issue 19037. https://github.com/dlang/phobos/commit/11b4a157352ca488dbe1201ece355a90978689bd Add testcase for issue 19037 unittest fix https://github.com/dlang/phobos/commit/c5d5f0ef46a183d9a99a0f772337d32c85f4bb61 Merge pull request #6619 from FeepingCreature/Nullable-use-moveEmplace Fix issue 19037: use move/moveEmplace in Nullable merged-on-behalf-of: Nathan Sashihara --
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 7/27/2018 4:15 PM, Laeeth Isharc wrote: Can you think of a pragmatic solution to Atila's problem? One way is for the C++ => D translator to gather all the members of a namespace before trying to emit them. Since D does not impose an order on declarations (unlike C++) it is not constrained to follow the same order.
[Issue 19124] New: Investigate using RYU to convert floats to strings
https://issues.dlang.org/show_bug.cgi?id=19124 Issue ID: 19124 Summary: Investigate using RYU to convert floats to strings Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: b2.t...@gmx.com Relying in the c standard library to do that is sometimes an issue. It's been encountered several time, e.g in std.json because snn.lib give different results that the gnu c library. It would also allow to get it to!string, format working at CTFE for float and double. Reference : https://github.com/ulfjack/ryu --
Re: C's Biggest Mistake on Hacker News
On Friday, 27 July 2018 at 15:04:12 UTC, Abdulhaq wrote: On Wednesday, 25 July 2018 at 23:27:45 UTC, Laeeth Isharc wrote: But making predictions is a tricky thing and mostly of not much value. I'm really surprised to hear you say this - so much money in the financial services is poured into making predictions, lots of them and as fast as possible. Isn't that one of the promises of D in that market? For me, I think that managing money is about choosing to expose your capital intelligently to the market, balancing the risk of loss against the prospective gain and considering this in a portfolio sense. Prediction doesn't really come into that I do personally sometimes write longer term pieces about markets - I wrote a piece in June 2012 asking if dollar is bottoming and I said it was. But that was based on a gestalt not some Cartesian predictive model. Whatever the reality about that, in the life of all humans the ability to make good predictions is fundamental to survival - if I cross the road now, will I be run over? If I build a chair to make money, will anyone buy it? I disagree. It's not the prediction that matters but what you do. It's habits, routines, perception, adaptation and actions that matter. What people think drives their behaviour isn't what actually does. See Dr Iain Macgilchrist Master and His Emissary for more. And in particular if you survive based on having insight then it's interesting to listen to what you say. If you are known as an expert but don't depend on having insight, it's interesting in how others perceive what you say and how that evolves, but the substance of your analysis is not - without skin in the game, it's just talk. Bernanke admits he has had no clue about economic developments before they happen. I used to trade a lot of gilts and the UK debt management office asked me to meet the IMF financial stability review guy in 2005. He had a bee in his bonnet about hedge funds and the dollar yen carry trade. I told him to look at the banks and what they were buying. He didn't listen. I had lunch with Kohn, Fed vice chair in summer 2006. I asked him about housing. He wasn't worried at all. So lots of people talk about all kinds of things. Look at how insightful they have been in the past. Predictions themselves aren't worth much - recognising change early is. And for what it's worth I think D is early in a bull market that will last for decades. The grumbling is funnily enough quite characteristic of such too. Likewise, if I am investing time in developing my skills to further my career, will learning D be a net benefit? It really depends. There are some very good jobs in D. If it should turn out we hired you some day then most likely you would find it quite satisfying and well paid and be rather glad you learnt D. If not and not someone else then who knows. I personally found following my intuition like in a Jack London novel to be better than trying to live by optimising and figuring out the best angle. But people are different and it's difficult to know. If you feel like learning D, do it. If it's purely a career move then there are too many factors to say. important question depends heavily on predicting the future of D (among many other things). If I use D for my startup, will it be the secret sauce that will propel us to the top, or will I be better off with JDK8 or modern C++? Things once alive tend to grow. The future is unknown if not unimaginable. I don't think life works like that. It's more like you pick something for your startup and the start-up fails because your business partner gets divorced. But through some unlikely chain of coincidences that leads to some better opportunity you never could have found by approaching it head on. So things are beyond calculation, but not beyond considering intuition and what resonates with you. See the work of my colleague Flavia Cymbalista - How George Soros Knows What He Knows. I think it's more interesting to be the change you wish to see in the world. This has a lovely ring but it doesn't mean not to assess / predict if what you do will provide a net benefit. It's really up to you what you do. People who make high stakes decisions - also commercially - I'm really not sure if predictions play the part you think they do. One little trick. If you have an insight nobody agrees with then you know you might be onto something when surprises start to come in your direction in a way nobody could have quite imagined. We are seeing this now with processor challenges for example.
[Issue 19123] -allinst gives undefined reference linker errors
https://issues.dlang.org/show_bug.cgi?id=19123 Basile B. changed: What|Removed |Added CC||b2.t...@gmx.com Severity|normal |regression --- Comment #1 from Basile B. --- actually it's a 2.080.0 regression. --
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Friday, 27 July 2018 at 22:50:20 UTC, Walter Bright wrote:
On 7/27/2018 10:28 AM, Atila Neves wrote:
But all I'm trying to do here is tell the D compiler how to
mangle symbols.
Namespaces have semantic implications, too, such as overload
resolutions. A namespace introduces a new scope, not just a
mangling.
> But why does this not compile?
> extern(C++, ns) { void foo(); }
> extern(C++, ns) { void bar(); }
For the same reason that:
struct ns { void foo(); }
struct ns { void bar(); }
doesn't. Being able to crack open a scope and stuff more
symbols into it at any point in a program is just madness :-)
However, one can do:
-- module A -
extern(C++, ns) { void foo(); }
-- module B -
extern(C++, ns) { void bar(); }
-- module C -
import A,B;
ns.foo(); // error, A.ns or B.ns?
A.ns.foo(); // ok
Because the compiler sees A.ns as utterly distinct from B.ns,
although the mangling will be the same - any conflicts will be
the linker's problem.
This is how, for example, extern(C) declarations can exist in
many files.
> Such a program can easily do that to `extern(C)`, but doing
that to `extern(C++)` is for some reason not allowed.
It is allowed. Just not reopening the same namespace.
Namespaces are a botch in C++, and it is understandable that
C++ code bases naturally have grown willy-nilly to utterly
ignore any encapsulation principles. It's analogous to how
monkey-patching in Ruby was seen initially as a cool feature,
but eventually people learned the hard way what a disastrous
idea it was.
Thanks for the explanation, Walter.
Can you think of a pragmatic solution to Atila's problem?
Because it's getting in the way of a decent prize - to be able
just to #include CPP headers and link with C++. Obviously some
work elsewhere still to do, but translation of headers is worth
quite a lot if you are a commercial user and don't have much time
to write a first exploratory version.
Already just having #include work for a lot of C libraries makes
an immense difference.
D "doesn't have libraries". Well there's some good stuff on
code.dlang.org plus every C library - a few of those, so I hear.
And with C++ on top it starts to become about as persuasive as
"there are no good jobs in D". (Reminder - we are hiring and we
pay well).
[Issue 19123] New: -allinst gives undefined reference linker errors
https://issues.dlang.org/show_bug.cgi?id=19123
Issue ID: 19123
Summary: -allinst gives undefined reference linker errors
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: zor...@gmail.com
Manjaro/Arch x86_64, dmd 2.081.1, ldc 1.10.0. run.dlang.io also shows the same
behaviour "since 2.080.1".
Reduced example, fails to link with -allinst but works without (dmd and ldc):
void main()
{
import std.stdio;
import std.datetime;
writefln("%s", Clock.currTime);
}
> $ dmd -allinst test.d
> /dlang/dmd/linux/bin64/../../src/phobos/std/range/primitives.d:273: error:
> undefined reference to
> '_D3std6format__T11hasToStringTSQBd8datetime7systime7SysTimeTaZ9__lambda2MFZ1S3putMFNaNbNiNfaZv'
> /dlang/dmd/linux/bin64/../../src/phobos/std/range/primitives.d:273: error:
> undefined reference to
> '_D3std6format__T11hasToStringTSQBd8datetime7systime7SysTimeTaZ9__lambda2MFZ1S3putMFNaNbNiNfaZv'
> /dlang/dmd/linux/bin64/../../src/phobos/std/range/primitives.d:273: error:
> undefined reference to
> '_D3std6format__T11hasToStringTSQBd8datetime7systime7SysTimeTaZ9__lambda2MFZ1S3putMFNaNbNiNfaZv'
> /dlang/dmd/linux/bin64/../../src/phobos/std/range/primitives.d:273: error:
> undefined reference to
> '_D3std6format__T11hasToStringTSQBd8datetime7systime7SysTimeTaZ9__lambda2MFZ1S3putMFNaNbNiNfaZv'
> collect2: error: ld returned 1 exit status
> Error: linker exited with status 1
--
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 7/27/2018 10:28 AM, Atila Neves wrote:
But all I'm trying to do here is tell the D
compiler how to mangle symbols.
Namespaces have semantic implications, too, such as overload resolutions. A
namespace introduces a new scope, not just a mangling.
> But why does this not compile?
> extern(C++, ns) { void foo(); }
> extern(C++, ns) { void bar(); }
For the same reason that:
struct ns { void foo(); }
struct ns { void bar(); }
doesn't. Being able to crack open a scope and stuff more symbols into it at any
point in a program is just madness :-)
However, one can do:
-- module A -
extern(C++, ns) { void foo(); }
-- module B -
extern(C++, ns) { void bar(); }
-- module C -
import A,B;
ns.foo(); // error, A.ns or B.ns?
A.ns.foo(); // ok
Because the compiler sees A.ns as utterly distinct from B.ns, although the
mangling will be the same - any conflicts will be the linker's problem.
This is how, for example, extern(C) declarations can exist in many files.
> Such a program can easily do that to `extern(C)`, but doing that to
`extern(C++)` is for some reason not allowed.
It is allowed. Just not reopening the same namespace.
Namespaces are a botch in C++, and it is understandable that C++ code bases
naturally have grown willy-nilly to utterly ignore any encapsulation principles.
It's analogous to how monkey-patching in Ruby was seen initially as a cool
feature, but eventually people learned the hard way what a disastrous idea it was.
[Issue 19119] App crashes with strange behavior of ctors/dtors from CPP
https://issues.dlang.org/show_bug.cgi?id=19119 --- Comment #13 from Manu --- (In reply to kinke from comment #12) > Something very similar is apparently already done for GC-allocated structs - > if they have a destructor, the TypeInfo pointer is stored right after the > actual instance, and a specially marked GC block is requested; see > rt.lifetime._d_newitemU(). Right. I think gcnew should implement a trick like that for C++ objects. I don't have time to look at it now though. Super-busy, which is why I was rushing to get all my C++ stuff in a month back. --
Re: Whence came UFCS?
On Friday, 27 July 2018 at 03:41:29 UTC, Sameer Pradhan wrote: During our Boston D Meetup today, we went through and deconstructed Walter's wonderfully elegant blog post from 2012 called "Component Programming in D" http://www.drdobbs.com/article/print?articleId=240008321=architecture-and-design I stumbled upon this gem (and another score or so articles on the digital mars site) a few days back, while following various hyperlinks, within and around the blog on Walter's take on what was C's biggest mistake which has been getting a lot of comments over the past few days. This post which I have been trying to digest bit-by-bit over the past few days, made me realize why I fell in love with D in the first place. To top it all, Steven played a lightening talk from 2018, called "values as types" by Andreas (https://youtu.be/Odj_5_pDN-U?t=21m10s) which is a parody on C++ and is so utterly ludicrous, we could not stop laughing. Anyway, back to the point. During the same period, but independent of the thread on C's mistake, I found that Kotlin has something called "Extension Functions" and "Extension Properties" (https://kotlinlang.org/docs/reference/extensions.html) via. the following article on Medium https://medium.com/@magnus.chatt/why-you-should-totally-switch-to-kotlin-c7bbde9e10d5 Specifically Item #14. What I saw/read seemed eerily familiar. Almost like a "wolf in sheeps clothing". The example screamed of UFCS. Then, later, while reading the above Kotlin documentation, I saw a reference being made to similar functionality in C# and Gosu (apparently a programming language that I have never heard of before today) called Extensions. Furthermore, I found that Project Lombok (https://projectlombok.org/features/experimental/ExtensionMethod) has tried to make this idiom/functionality available in Java through a @ExtensionMethod annotation. This also almost exactly represent UFCS functionality, though much more cludgy, I must say. Therefore, after reading the word "Extension" in three different contexts, I started wondering and various questions came to mind, starting with---Whence came UFCS? a. Did Walter and/or Andrei invent it independently of C#? b. Was it called UFCS in some other language? c. Were they not aware of Extensions when they coined UFCS? d. Are UFCS and Extensions really one and the same thing? e. If not, what is/are the difference(s)? And is this why a different term/acronym was coined? As far as I can tell a Google search on UFCS leads to only material on D and a Wikipedia entry mentioning Stroustrup and Sutter's proposal from 2016 to extend C++ to have this facility. It is likely that the Wikipedia article is severely incomplete in its historical connections as there is no mention of C# or that of Walter's 2012 Dr. Dobbs post which already lists it towards the end---in the list of features that D has which allows the creation of elegant components---among other dozen or so features. In the end I thought I might as well dump my thoughts on the D forum and hear straight from the horse's (or horses') mouth(s)---so to speak. -- Sameer I remember reading an article that Andrei wrote a long time ago that cited an older language as the inspiration for UFCS, but it was probably from around 2007 where UFCS for arrays was already well-established (I never knew that it was actually a bug at one point). I don't remember what that language was unfortunately.
Re: A vibe.d thing
On 7/27/18 3:44 PM, Russel Winder wrote: On Fri, 2018-07-27 at 15:25 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: […] Oh, it looks like you specified once. Hm... that seems to me like it should work. Looks like IOMode is ignored: https://github.com/vibe-d/vibe.d/blob/a9589d955f10bd076a67d47ace0c78c fd3aa8246/core/vibe/core/drivers/libevent2_tcp.d#L285 So, no, there isn't a correct way to do this, it's unimplemented. Present a function with implied UNIX style system call behaviour and then don't bother doing it properly. Just a wee bit annoying. I shall go away and be grumpy. Haha, I don't blame you. The docs should say in bold letters (NOT IMPLEMENTED). As for systems implemented using vibe.d, how the do they deal with this crap? I'm guessing they don't use it, but use peek instead (or maybe peek to get the size, and then read to get the data). I'd be surprised if there isn't some better I/O options in vibe.d. I mainly use the higher-level features. -Steve
Re: A vibe.d thing
On Fri, 2018-07-27 at 15:25 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: […] > > Oh, it looks like you specified once. Hm... that seems to me like it > should work. > > Looks like IOMode is ignored: > > https://github.com/vibe-d/vibe.d/blob/a9589d955f10bd076a67d47ace0c78c > fd3aa8246/core/vibe/core/drivers/libevent2_tcp.d#L285 > > So, no, there isn't a correct way to do this, it's unimplemented. Present a function with implied UNIX style system call behaviour and then don't bother doing it properly. Just a wee bit annoying. I shall go away and be grumpy. As for systems implemented using vibe.d, how the do they deal with this crap? I may be better able to deal with this in the morning. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Whence came UFCS?
On Friday, 27 July 2018 at 03:41:29 UTC, Sameer Pradhan wrote: Therefore, after reading the word "Extension" in three different contexts, I started wondering and various questions came to mind, starting with---Whence came UFCS? The answer I always say back in the day for the functionality was that it was a bug for arrays. The term UFCS though is much newer and just comes from discussion for applying the array bug to all types. Who started it, why it caught on I don't know. The use of the term Extension I believe is because of the implementation/syntax approach used to describe this behavior in C#. In C# you don't have free functions, so instead you need a new class with static methods. This makes the new class act as an "extension" of another object. D having free functions and the functionality working on more than objects means "Extension" wouldn't be a good term to describe it.
[Issue 19119] App crashes with strange behavior of ctors/dtors from CPP
https://issues.dlang.org/show_bug.cgi?id=19119 --- Comment #12 from ki...@gmx.net --- Something very similar is apparently already done for GC-allocated structs - if they have a destructor, the TypeInfo pointer is stored right after the actual instance, and a specially marked GC block is requested; see rt.lifetime._d_newitemU(). --
Re: A vibe.d thing
On 7/27/18 3:18 PM, Steven Schveighoffer wrote: On 7/27/18 3:02 PM, Russel Winder wrote: I have posted to the vibe.d forum, but I hate forums, and it looks like a months worth of questions haven't been read yet, so please excuse repeating here – I need an fairly definitive answer pdq in order to finish my answer to the CVu Code Critique 112. The deadline is in three days. http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/ 57605/ cf. https://vibed.org/api/vibe.core.stream/InputStream.read ubyte[256] buffer; auto n = req.bodyReader.read(buffer, IOMode.once); appears to work fine as long as there are 256 ubytes to read. If however the end of stream means there are less than 256 ubytes available then an exception is thrown. At first sight this seems inconsistent with the read returning the number of ubytes read. Or am I missing something? Maybe IOMode.immediate or .once? https://vibed.org/api/eventcore.driver/IOMode Oh, it looks like you specified once. Hm... that seems to me like it should work. Looks like IOMode is ignored: https://github.com/vibe-d/vibe.d/blob/a9589d955f10bd076a67d47ace0c78cfd3aa8246/core/vibe/core/drivers/libevent2_tcp.d#L285 So, no, there isn't a correct way to do this, it's unimplemented. -Steve
Re: A vibe.d thing
On 7/27/18 3:02 PM, Russel Winder wrote: I have posted to the vibe.d forum, but I hate forums, and it looks like a months worth of questions haven't been read yet, so please excuse repeating here – I need an fairly definitive answer pdq in order to finish my answer to the CVu Code Critique 112. The deadline is in three days. http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/ 57605/ cf. https://vibed.org/api/vibe.core.stream/InputStream.read ubyte[256] buffer; auto n = req.bodyReader.read(buffer, IOMode.once); appears to work fine as long as there are 256 ubytes to read. If however the end of stream means there are less than 256 ubytes available then an exception is thrown. At first sight this seems inconsistent with the read returning the number of ubytes read. Or am I missing something? Maybe IOMode.immediate or .once? https://vibed.org/api/eventcore.driver/IOMode -Steve
[Issue 19119] App crashes with strange behavior of ctors/dtors from CPP
https://issues.dlang.org/show_bug.cgi?id=19119 --- Comment #11 from ki...@gmx.net --- (In reply to Manu from comment #10) > or maybe there's some opportunity to make gcnew wrap C++ class > allocations in a thin D class that forwards the destructor? I guess something like having specially-marked GC blocks for C++ objects and gcnew prepending the C++ dtor (or D ClassInfo) address right before the actual class instance would work => 1 pointer overhead per GC-allocated C++ object to make it destructible during garbage collection. --
[Issue 19119] App crashes with strange behavior of ctors/dtors from CPP
https://issues.dlang.org/show_bug.cgi?id=19119 --- Comment #10 from Manu --- Right, and that goes back to my original point; the GC doesn't know the memory is a C++ class, and doesn't know how to destruct. So either, use the GC under the assumption the destructor will never be called... or maybe there's some opportunity to make gcnew wrap C++ class allocations in a thin D class that forwards the destructor? --
A vibe.d thing
I have posted to the vibe.d forum, but I hate forums, and it looks like a months worth of questions haven't been read yet, so please excuse repeating here – I need an fairly definitive answer pdq in order to finish my answer to the CVu Code Critique 112. The deadline is in three days. http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/ 57605/ cf. https://vibed.org/api/vibe.core.stream/InputStream.read ubyte[256] buffer; auto n = req.bodyReader.read(buffer, IOMode.once); appears to work fine as long as there are 256 ubytes to read. If however the end of stream means there are less than 256 ubytes available then an exception is thrown. At first sight this seems inconsistent with the read returning the number of ubytes read. Or am I missing something? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
[Issue 19119] App crashes with strange behavior of ctors/dtors from CPP
https://issues.dlang.org/show_bug.cgi?id=19119 --- Comment #9 from ki...@gmx.net --- Ouch, I totally overlooked the missing fields on the D side too. The GC now releases the memory correctly - without trying to destruct the extern(C++) objects first (independent from virtual-ness of dtor), which might be an issue in its own right. --
Re: Looking for the article comparing D to Ada and others
I had no idea of the DoD's Steelman requirements (https://en.wikipedia.org/wiki/Steelman_language_requirements) I found another documents that has the same table that was on the website listed in an earlier post. Here are the individual links: https://www.dwheeler.com/steelman/steeltab.htm http://jedbarber.id.au/steelman.html I thought it might be nice to combine those two tables in one below. D is really up there! |--++-++-+| | Language | No | Partial | Mostly | Yes | Mostly/Yes | |--++-++-+| | D| 7 | 15 | 25 | 66 |81% | | Parasail | 11 | 6 | 11 | 85 |85% | | Pascal | 19 | 16 | 11 | 67 |69% | | Rust | 12 | 19 | 23 | 59 |73% | |--++-++-+| | Ada | 3 | 5 | 11 | 94 |93% | | C| 32 | 21 | 16 | 44 |53% | | C++ | 19 | 17 | 23 | 54 |68% | | Java | 20 | 12 | 22 | 59 |72% | |--++-++-+| -- Sameer
[Issue 19073] core.internal.hash should not bitwise hash representations of floating point numbers
https://issues.dlang.org/show_bug.cgi?id=19073 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19073] core.internal.hash should not bitwise hash representations of floating point numbers
https://issues.dlang.org/show_bug.cgi?id=19073 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/7ebe816eaeb83394558ae5467920eebc9ebde2d9 Fix Issue 19073 - core.internal.hash should not bitwise hash representations of floating point numbers Other minor improvements: - Make hash of static arrays more efficient. - More precise test for when memberwise hashing of structs is necessary (fewer false positives). - Make required return type of `toHash` less brittle. - Special handling for structs wrapping a single element (like std.typecons.Typedef). - Infer scope const for some arrays. - Infer scope const for some structs and unions. - Infer scope const and specialize for final classes that don't override toHash. - Infer scope const and remove unnecessary auto ref for some enums. - As previously, uint and int have same hash. - Slightly clean up bytesHash. https://github.com/dlang/druntime/commit/33659bf5897881537436459229f6c228d6776d89 Merge pull request #2240 from n8sh/core-hash-misc-improvements Fix Issue 19073 - core.internal.hash should not bitwise hash representations of floating point numbers, plus minor improvements and refactoring merged-on-behalf-of: Nathan Sashihara --
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 27.07.2018 19:28, Atila Neves wrote:
I understand that being able to "reopen" namespaces in C++ is
contentious - anybody can add to the `std` namespace in their own code.
D doesn't have anything like it, and instead has packages and modules.
So far, so good.
But why does this not compile?
extern(C++, ns) { void foo(); }
extern(C++, ns) { void bar(); }
Both of the extern(C++, ns) declarations create a separate namespace
declaration. (Which is needed to allow ns.foo and ns.bar respectively.)
I.e. the reason is that it was easier to implement in the compiler.
There might be a way to add support for it by overriding overloadInsert
in Nspace.
Re: Is there any good reason why C++ namespaces are "closed" in D?
This limitation really seems to make no sense, especially since you can split up a C++ namespace across multiple D modules, just not inside a single module.
[Issue 19119] App crashes with strange behavior of ctors/dtors from CPP
https://issues.dlang.org/show_bug.cgi?id=19119 --- Comment #8 from Manu --- (In reply to Vladimir Marchevsky from comment #7) > Sounds logical. I've tried to additionally export Bar, map it in D and also > to add Foo::a and Foo::b to mapping to make it full. Problem has gone and it > seems to work correct without crashes or memory leaks. Yeah, sorry, I didn't notice that the classes were not matching! If you're going to allocate instances of a class, they need to be the same size. > But how does it happen to work under some conditions before (like with > non-virtual dtor)? Does "virtual" change used methods to create/delete > objects somehow or was that sort of random luck?.. You were lucky. The CPP ctor/dtor were assigning and destroying a,b which were outside of the memory allocation (since you didn't define them in the class that D allocated. It's likely that there's a minimum allocation granularity (like 16 bytes or something) and those members just happened to fit inside... but when you added the vtable, the class got bigger, maybe b was outside of the minimum allocation block... or lots of possibilities. You were writing to unallocated memory; anything could happen! --
Is there any good reason why C++ namespaces are "closed" in D?
I understand that being able to "reopen" namespaces in C++ is
contentious - anybody can add to the `std` namespace in their own
code. D doesn't have anything like it, and instead has packages
and modules. So far, so good.
But why does this not compile?
extern(C++, ns) { void foo(); }
extern(C++, ns) { void bar(); }
I could maybe understand the limitation if those functions had
bodies since we'd be importing the namespace functionality from
C++ in a sense (and even then I'm not sure it's a big enough
deal). But all I'm trying to do here is tell the D compiler how
to mangle symbols.
Why would this matter? Imagine a project that parses C++ headers
and translates them to D declarations. Imagine that project is
trying to parse `#include `. There will be many, many
instances of `namespace std` in there, but such a
not-so-hypothetical program can't just go through them and open
and close `extern(C++, std)` as it goes along. Such a program can
easily do that to `extern(C)`, but doing that to `extern(C++)` is
for some reason not allowed.
(is there even any semantic difference? extern(C) for a 2nd time
is just reopening the global namespace!)
One could simply manually `pragma(mangle)` everything up the
wazoo, but unfortunately that doesn't work for templates, which,
as it turns out, is pretty much everything inside the `std`
namespace.
My only solution is to keep track of all namespaces at all times
and then sort the declarations by namespace, which:
1) Is incredibly tedious
2) Might cause problems with the order of declarations,
especially if macros are involved.
I can only assume nobody has tried calling a large C++ library
from D (Qt doesn't count, no namespaces). Imagine manually
organising namespaces in one huge bindings file instead of being
able to copy the file layout of the C++ headers!
Sigh.
Atila
Re: Whence came UFCS?
Wow! I am glad to see so many responses! Thanks for your indulgence. So, to summarize, the concept (no pun intended) has been around for a while in D---originally in the context of arrays. It just might have been a bug, or an unintended side-effect. I intend to read the archival posts and might have something to say later. -- Sameer PS: I realize that I am a stickler for history, or rather historical contexts related to technology or research that I am involved in, and more recently regarding programming language concepts. The culprit is probably the fact that I have been teaching programming languages course (or, taught one semester of it, and plan to teach it again in Spring) which has allowed me to learn of the origins of so many concepts which we sometimes take for granted today, but were part of some old languages. PS1: I didn't want to respond to a particular thread, but there is no way in this forum to write a generic response to multiple posts so I am picking one as the anchor.
Re: Whence came UFCS?
On Fri, Jul 27, 2018 at 03:41:29AM +, Sameer Pradhan via Digitalmars-d
wrote:
[...]
> Whence came UFCS?
[...]
As far as I know, UFCS came about from a particular interpretation of
TDPL (Andrei's book). Andrei was talking about the range API, and
inserted a little note about how native arrays can be made into ranges
by adopting the convention that if:
arr.func(...)
cannot be resolved as a member function, then the compiler would rewrite
it as:
func(arr, ...)
instead. This would then allow generic code to be written as:
while (r.empty) {
doSomething(r.front);
r.popFront();
}
without needing to special case the code for native arrays.
Initially, this was only implemented for arrays as a special case, and
some people read Andrei's description as applying only to arrays.
However, others (including myself) read it as a general principle that
ought to apply to all types, even though at the time the compiler had
only implemented this for the array case.
After quite a lot of debate, eventually somebody (I believe it was Kenji
-- man I still miss that guy) implemented a PR for it, and after quite a
bit more controversy, the PR was merged. That was when UFCS became a
reality. The rest, as they say, was history.
T
--
People who are more than casually interested in computers should have at least
some idea of what the underlying hardware is like. Otherwise the programs they
write will be pretty weird. -- D. Knuth
Re: Moving druntime into the DMD repository
On Friday, July 27, 2018 6:28:07 AM MDT Seb via Digitalmars-d wrote: > On Friday, 27 July 2018 at 12:04:18 UTC, Jonathan M Davis wrote: > > On Friday, July 27, 2018 5:03:50 AM MDT Seb via Digitalmars-d > > > > wrote: > >> What do you think? > >> -- > >> > >> - Has the dmd/druntime split being annoying you too? > >> - Do you have a better suggestion? > >> - Would this break your workflow in a drastic way? > > > > It would break all existing tools and scripts that are used to > > build the existing repos - many of which are not official > > tools. So, yes, it would be very annoying. > > FWIW I don't think this would be the case. All build scripts I > have seen call the Makefile (except for LDC/GDC, of course). The > Makefile build would continue to work at any stage. I'd be _very_ surprised if it doesn't break the tools that I use to build the repos and keep them in sync. The biggest ones to look at though would probably be DVM and digger. I'd probably be okay with the build process being changed if we were switching to something that was more maintainable than the makefiles, but to rearrange repos? Not so much. In general, the build process is one thing that I'd very much not like to see touched without something that's going to significantly improve it, because pretty every time someone mucks with it, I have to waste time fixing stuff so that it will build for me again, and usually, the changes don't seem like they really improved things, just moved them around. > > If the repos are merged, then we're forced to either give some > > of those folks dmd merge rights or make the smaller pool of > > folks who have merge rights for dmd deal with those PRs. > > This shouldn't be a problem either as GitHub's CODEOWNERS files, > are made for this use case and > all we need would be sth. this: > > * @team-dmd > src/druntime @team-druntime Well, that would certainly help, but it still seems like things that should be separate are being shoved together. dmd and druntime are separate beasts and IMHO should be kept as such. Also, even if the codeowners thing deals with the permissions, it still makes it harder for folks to look through the PR list for stuff that's relevant to what they might be merging, since the dmd and druntime PR queues would presumably be the same one at that point. Anyone who works on druntime but not dmd would have to deal with a ton of dmd PRs, whereas currently, they don't. _Maybe_ it would make sense if we were talking about putting all three repos in one with clear subdirectories for the three projects, since then the repos could be completely in sync at all times, and it would be easier for folks to figure out how to build everything, whereas right now, it's a bit of a pain to deal with it (hence when a number of us have written scripts or tools to deal with the process), but I don't know if that really makes sense when everything is considered - especially with how the PRs would all be in one bucket. We have enough problems with PRs being properly reviewed in a timely manner as it is. Either way, just putting two of them in a single repo seems like it's causing all of the problems that merging them all together would cause without really getting any of the benefits. > > The dependencies between the three repos do occasionally cause > > problems, but overall, I think that the separation makes a lot > > of sense. > > It causes A LOT of problems in terms of maintaining the CI and > build scripts, > moving things between DMD and adding test for druntime features > to the dmd testsuite. Does it really cause that many problems? If so, I'd honestly rather that we look into adjusting how the CI works than merging repos. And if the problem si that we have a lot of PRs where we need a dmd and druntime PR at the same time, then I think that that's something to be concerned about. I'd be worried if the compiler API needs to be changed that frequently. And from a code cleanliness and maintenance standpoint, I really don't think that it makes sense to merge dmd and druntime. Some pieces are interconnected, yes, but most of druntime is a very separate thing, and for the most part, it should be treated as separate. - Jonathan M Davis
Re: Whence came UFCS?
On Friday, July 27, 2018 8:09:02 AM MDT Simen Kjærås via Digitalmars-d wrote: > On Friday, 27 July 2018 at 13:38:26 UTC, Steven Schveighoffer > > wrote: > > On 7/27/18 7:24 AM, Simen Kjærås wrote: > >> Arrays' .reverse, .sort and others were added in 0.24, but I > >> can't find a download for anything before 0.50. > > > > Reverse and sort were properties (compiler built-ins), not > > extensions. If it existed in 2002, it's safe to say it was > > there pretty much from the beginning. > > From what I recall, UFCS for arrays were essentially a bug - an > unintended side effect of how the properties were implemented. > But it's been 15 years, so I can't really trust my memory. :p I vaguely recall the whole property thing being a bug, but I don't trust my memory on that at this point. - Jonathan M Davis
Re: Whence came UFCS?
On 7/27/18 10:09 AM, Simen Kjærås wrote: On Friday, 27 July 2018 at 13:38:26 UTC, Steven Schveighoffer wrote: On 7/27/18 7:24 AM, Simen Kjærås wrote: Arrays' .reverse, .sort and others were added in 0.24, but I can't find a download for anything before 0.50. Reverse and sort were properties (compiler built-ins), not extensions. If it existed in 2002, it's safe to say it was there pretty much from the beginning. From what I recall, UFCS for arrays were essentially a bug - an unintended side effect of how the properties were implemented. But it's been 15 years, so I can't really trust my memory. :p Heh, that pre-dates my D lifetime. Interesting if it was a bug! -Steve
Re: Initialise non-copyable, non-default-constrauctable member struct
On Friday, 27 July 2018 at 13:06:10 UTC, aliak wrote: On Friday, 27 July 2018 at 13:05:07 UTC, aliak wrote: https://run.dlang.io/is/lLrUiq Sorry: https://run.dlang.io/is/20FUoj Thanks, you are right, but it seems that I have reduced my issue too much, as it still does not work with my actual case. I will try to properly reduce my code to present my issue. I think that the simple example can be fully figured out statically, but my case not.
Re: How come isMutable returns true for structs that cannot be modified
On Friday, 27 July 2018 at 14:48:06 UTC, Steven Schveighoffer
wrote:
On 7/27/18 9:10 AM, aliak wrote:
import std.traits: isMutable;
struct S {
immutable int i = 3;
}
pragma(msg, isMutable!S);
void main() {
S s;
s = S();
}
isMutable only takes the type into account, it doesn't look to
see if all the internals are mutable.
It literally is this:
enum bool isMutable(T) = !is(T == const) && !is(T == immutable)
&& !is(T == inout);
And is there a trait that takes the transitivity of
immutability in to account?
I think you are looking for
https://dlang.org/phobos/std_traits.html#isAssignable
-Steve
Ah! Yes I think I am. Thanks!
Re: C's Biggest Mistake on Hacker News
On Wednesday, 25 July 2018 at 23:27:45 UTC, Laeeth Isharc wrote: But making predictions is a tricky thing and mostly of not much value. I'm really surprised to hear you say this - so much money in the financial services is poured into making predictions, lots of them and as fast as possible. Isn't that one of the promises of D in that market? Whatever the reality about that, in the life of all humans the ability to make good predictions is fundamental to survival - if I cross the road now, will I be run over? If I build a chair to make money, will anyone buy it? Likewise, if I am investing time in developing my skills to further my career, will learning D be a net benefit? This important question depends heavily on predicting the future of D (among many other things). If I use D for my startup, will it be the secret sauce that will propel us to the top, or will I be better off with JDK8 or modern C++? I think it's more interesting to be the change you wish to see in the world. This has a lovely ring but it doesn't mean not to assess / predict if what you do will provide a net benefit.
Re: How to avoid inout type constructor with Optional type wrapper undoing string type
On 7/23/18 2:39 PM, aliak wrote:
Hi,
I'm playing around with an Optional wrapper type. It stores a type T and
a bool that defines whether a value is defined or not:
struct Optional(T) {
T value;
bool defined = false;
this(U : T)(auto ref inout(U) value) inout {
this.value = value;
this.defined = true;
}
}
Don't use inout here. The point of inout on the constructor is to
*transfer* the mutability of the parameter to the struct instance. But
you want to simply copy the type into the struct (an
immutable(Optional!T) is quite useless, no?)
Just use U, not inout(U), and don't put inout on the constructor.
-Steve
Re: How come isMutable returns true for structs that cannot be modified
On 7/27/18 9:10 AM, aliak wrote:
import std.traits: isMutable;
struct S {
immutable int i = 3;
}
pragma(msg, isMutable!S);
void main() {
S s;
s = S();
}
isMutable only takes the type into account, it doesn't look to see if
all the internals are mutable.
It literally is this:
enum bool isMutable(T) = !is(T == const) && !is(T == immutable) && !is(T
== inout);
And is there a trait that takes the transitivity of immutability in to
account?
I think you are looking for
https://dlang.org/phobos/std_traits.html#isAssignable
-Steve
Re: Whence came UFCS?
On Friday, 27 July 2018 at 14:31:24 UTC, Mike Parker wrote: This is the earliest thread I could find in the archives, based solely on searching for "array" in the title. I almost fell down the rabbit hole reading some of those old threads, as the ones I did look at tickled my memory. Fortunately, I caught myself in time. https://digitalmars.com/d/archives/digitalmars/D/16452.html And even earlier: https://digitalmars.com/d/archives/digitalmars/D/9779.html
Re: How to get an inout constructor working with a template wrapper
On 7/27/18 9:29 AM, aliak wrote:
Ok, thanks to Simen from another post [0], I just figured out what the
correct constructor and factory method for a template wrapper should be:
https://run.dlang.io/is/S4vHzL
struct W(T) {
T val;
this(U : T, this This)(auto ref U val) {
this.val = val;
}
}
auto wrap(T)(auto ref T t) {
return W!T(t);
}
Seems to catch all cases!
And instantiate a new template for all mutabilities. Whereas inout would
only instantiate one (and disallows modification of val if not const or
immutable).
-Steve
Re: How to get an inout constructor working with a template wrapper
On 7/23/18 8:02 AM, aliak wrote:
On Sunday, 22 July 2018 at 23:11:09 UTC, Ali Çehreli wrote:
Without much confidence on my side, first, I think you need to make
the constructor parameter inout(T) as well. Otherwise, you may be
making a const(W!T) initialized with a non-const T.
After that, I like the "type constructor" syntax in main_alt() below
(which works) but a better approach is to use a convenience function
like wrap() below:
struct W(T) {
T val;
this(inout(T) val) inout {
this.val = val;
}
}
class C {}
void main_alt() {
auto a = W!C(new C);
auto b = immutable W!(immutable C)(new C);
}
auto wrap(T)(inout T t) {
return inout(W!T)(t);
}
void main() {
auto a = wrap(new C);
auto b = wrap(new immutable(C));
}
Ali
"taklitlerinden sakınınız" :o)
Thank you Ali! That helped :) I've gotten most of it sorted out now, and
the factory wrap is definitely the way to go, it also turned out that
inout(T) and inout T (so inout without parens) was surprisingly
different (maybe it's a bug? - to test you can remove the parens around
U on line 3 in this sample: https://run.dlang.io/is/gd5oxW
This seems like a bug to me.
The semantic difference is that inout(U) means the TYPE inout(U),
whereas inout U means the variable U has the STORAGE CLASS inout, which
also happens to make it an inout(U) type. As far as I know, the storage
class inout shouldn't have any other effect on the semantic meaning.
I can't imagine any difference there, but it appears to not recognize
that return should be inferred? I don't know.
Also over there, line 24:
auto si = wrap!(immutable int)(3);
seems to be giving problems. Any ideas there? Error is:
onlineapp.d(8): Error: inout on return means inout must be on a
parameter as well for pure nothrow @nogc @safe
inout(W!(immutable(int)))(immutable(int) t)
onlineapp.d(23): Error: template instance
`onlineapp.wrap!(immutable(int))` error instantiating
The problem here is that inout(immutable(int)) is equivalent to
immutable(int).
That is, all flavors of mutability are equivalent to immutable(int):
/*mutable*/(immutable(int)) => immutable(int)
const(immutable(int)) => immutable(int)
immutable(immutable(int)) => immutable(int)
So the compiler really looks at your wrap instantiation like this;
inout(W!(immutable(int))) wrap(immutable(int) t)
which triggers the (really bad) message.
I'd ask, why are you even worrying about explicit instantiation? Why not
just wrap(3)?
or (if you really want to test it) wrap(immutable(int)(3))?
To make it compile successfully you can either:
1) Chance immutable to const, then it works for some reason.
Because immutable(const(int)) => immutable(int), so the compiler can't
remove the inout behind your back.
2) Change the line to: "auto si = wrap(cast(immutable int)3);" - i.e. do
not explicitly provide type information.
Yep, do this :)
Note that the point of inout is 2-fold:
1. reduce template instantiations. In fact, wrap!int works for const,
mutable and immutable int.
2. ENSURE that the data isn't modified, even in the case of mutable
parameters.
-Steve
Re: Whence came UFCS?
On Friday, 27 July 2018 at 14:12:53 UTC, Mike Parker wrote: On Friday, 27 July 2018 at 14:09:02 UTC, Simen Kjærås wrote: From what I recall, UFCS for arrays were essentially a bug - an unintended side effect of how the properties were implemented. But it's been 15 years, so I can't really trust my memory. :p You're not alone! That's how I remember it as well. This is the earliest thread I could find in the archives, based solely on searching for "array" in the title. I almost fell down the rabbit hole reading some of those old threads, as the ones I did look at tickled my memory. Fortunately, I caught myself in time. https://digitalmars.com/d/archives/digitalmars/D/16452.html
[Issue 19122] New: Multiple destruction of union members
https://issues.dlang.org/show_bug.cgi?id=19122
Issue ID: 19122
Summary: Multiple destruction of union members
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: safe
Severity: critical
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: simen.kja...@gmail.com
@safe unittest {
import std.stdio : writeln;
struct S1 {
int* p;
~this() {
writeln("Writing garbage to random memory: ", p);
//*p = 80085;
}
}
struct S2 {
union {
S1 a;
int b;
}
int index;
this(S1 s) {
a = s;
index = 0;
}
this(int n) {
b = n;
index = 1;
}
}
S2 s = 123456;
}
The above code shows that destructors of union members will be called when the
surrounding struct is destructed. In this case, this leads to reinterpretation
of an int as a pointer, but worse could happen.
If multiple union members have destructors, all of them are called, regardless
of what's currently in the union.
According to https://github.com/dlang/dmd/pull/5830:
"Unrestricted unions can have fields that have destructors, postblits, or
invariants. It's up to the user to call them correctly, the compiler does not
automatically generate calls to them."
This is clearly not what's happening here. Worse, there's no way to tell the
compiler not to call the destructors, short of hiding the actual types behind
ubyte[]/void[] and casting.
As a crowning achievement, this happens in @safe.
--
Re: An Optional!T and the implementation of the underlying type's opUnary
On Friday, 27 July 2018 at 12:52:09 UTC, aliak wrote:
On Thursday, 26 July 2018 at 06:37:41 UTC, Simen Kjærås wrote:
As for assigning to Optional!(immutable int), the language
basically forbids this (cannot modify struct with immutable
members). It would, as you say, cause problems when you can
get a pointer to the contents.
So is this undefined behaviour?
import std.stdio;
struct S(T) {
T value;
void opUnary(string op)() inout {
mixin(op ~ "cast(T)value;");
}
}
void main() {
immutable a = S!int(2);
++a;
}
It's the exact same as the top two lines of this:
void main() {
immutable int a = 2;
++*cast(int*)
assert(a == 3); // Will trigger on DMD 2.081.1
}
So yes, it's casting away immutable and modifying it, which is UB.
--
Simen
Re: Whence came UFCS?
On Friday, 27 July 2018 at 14:09:02 UTC, Simen Kjærås wrote: From what I recall, UFCS for arrays were essentially a bug - an unintended side effect of how the properties were implemented. But it's been 15 years, so I can't really trust my memory. :p You're not alone! That's how I remember it as well.
Re: Moving druntime into the DMD repository
On 7/27/18 7:03 AM, Seb wrote: This a thread to explore whether it would be feasible to do so. Motivation -- DRuntime and DMD heavily depend on each other. It happens very often that a PR needs to touch both and then a complicated three-step (or sometimes four-step PR series) needs to be done to keep the CIs happy. Moreover, as the whole testsuite is at dmd, it happens more often that an error is caught in the testsuite, but would require a druntime PR or the opposite you make a PR to druntime and want its accompanying test to be checked by the CI. The auto tester is home-grown. We can adjust it if needed to test PRs in tandem. In fact, I believe we used to use Daniel Murphy's branch to test mutual PRs this way (kind of ad-hoc, but it worked, and was not frequently needed). I'd MUCH rather not merge these two repos. Note that this sometimes even happens with Phobos too! If needed, I'd rather there be an interface on the auto-tester to tag which mutual PR is needed from any of the other repos. -Steve
Re: Whence came UFCS?
On Friday, 27 July 2018 at 13:38:26 UTC, Steven Schveighoffer wrote: Reverse and sort were properties (compiler built-ins), not extensions. If it existed in 2002, it's safe to say it was there pretty much from the beginning. -Steve I came to D in 2003. I recall this coming up in the forums now and again by people discovering it for the first time and wondering why it only worked with arrays. I remember thinking it was a pretty big deal when it was expanded to work in the general case. I'm sure I wrote about it on my old blog, but now I can't find my database backup to verify.
Re: Whence came UFCS?
On Friday, 27 July 2018 at 13:38:26 UTC, Steven Schveighoffer wrote: On 7/27/18 7:24 AM, Simen Kjærås wrote: Arrays' .reverse, .sort and others were added in 0.24, but I can't find a download for anything before 0.50. Reverse and sort were properties (compiler built-ins), not extensions. If it existed in 2002, it's safe to say it was there pretty much from the beginning. From what I recall, UFCS for arrays were essentially a bug - an unintended side effect of how the properties were implemented. But it's been 15 years, so I can't really trust my memory. :p -- Simen
Re: Whence came UFCS?
On Friday, 27 July 2018 at 05:22:17 UTC, Joakim wrote: On Friday, 27 July 2018 at 03:41:29 UTC, Sameer Pradhan wrote: During our Boston D Meetup today, we went through and deconstructed Walter's wonderfully elegant blog post from 2012 called "Component Programming in D" [...] Extension methods were added to C# 3.0 in 2007, UFCS was discussed as a generalization of the concept to free functions at that year's DConf, fully implemented years later: https://forum.dlang.org/thread/htjuut$av2$1...@digitalmars.com The DConf slides linked from that old thread list this 2000 Scott Meyers article as an inspiration for UFCS: http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197
Re: Moving druntime into the DMD repository
On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote: This a thread to explore whether it would be feasible to do so. Motivation -- [...] Not much. - Do you have a better suggestion? No. - Would this break your workflow in a drastic way? No, don't really use the official repos anymore, been using the LDC forks instead, so doesn't matter to me how the official git repos for dmd are organized. LDC splits off the DMD testsuite as its own git repo too, so any merged directory can always be split off to another git repo if wanted: https://github.com/ldc-developers/dmd-testsuite
Re: Whence came UFCS?
On 7/27/18 7:24 AM, Simen Kjærås wrote:
On Friday, 27 July 2018 at 10:30:07 UTC, Jonathan M Davis wrote:
It evolved out of D's member function call syntax for arrays -
basically, for years before we had UFCS in D, we had UFCS for arrays.
However, when and how that was added to arrays, I don't know. I don't
recall it ever not being in the language, but I never used D1, and I
don't know if it had it. At minimum, it's been in D since early D2, if
not much earlier. I'd have to do a lot of spelunking through old
releases to figure out when it was added.
Certainly, the origins of UFCS in D do not come from making it
possible to extend user-defined types with member functions. It comes
from wanting member function call syntax when using arrays (probably
aimed primarily at strings, but I don't know). It's just that later it
was proposed to extend it so that it would work with any type and thus
make the member function call syntax universal.
This compiles in DMD 0.50 (oldest version on the download page, nov 20,
2002), so I think it's safe to say it's been around for a while:
void fun(int[] arr) {}
void main() {
int[] a;
a.fun();
}
Arrays' .reverse, .sort and others were added in 0.24, but I can't find
a download for anything before 0.50.
Reverse and sort were properties (compiler built-ins), not extensions.
If it existed in 2002, it's safe to say it was there pretty much from
the beginning.
-Steve
Re: How to get an inout constructor working with a template wrapper
On Monday, 23 July 2018 at 14:46:32 UTC, Timoses wrote:
On Monday, 23 July 2018 at 12:02:58 UTC, aliak wrote:
[...]
Both of these seem to work (as you pointed out)
// immutable(W!int)
auto si = wrap!(int)(cast(immutable)3); // or
wrap(cast(immutable)3);
// W!(immutable(int))
auto si2 = W!(immutable int)(3);
[...]
I don't know why
wrap!(immutable int)(3);
is not working. The error message
"Error: inout on return means inout must be on a parameter
as well for pure nothrow @nogc @safe
inout(W!(immutable(int)))(return immutable(int) t)"
sounds very odd and not at all helpful, at least regarding that
removing immutable from the template argument works.
[...]
The depths of D. Why does the following only work with "return
ref"?
struct W(T) {
T val;
this(U : T)(auto ref inout U val) inout {
pragma(msg, typeof(val));
this.val = val;
}
}
// Fails without "return ref" (escaping t warning...)
auto wrap(T)(return ref inout T t) {
return inout W!T(t);
}
class C {}
void main() {
immutable C ci = new immutable C;
auto i = wrap(im);
pragma(msg, typeof(i));
}
Ok, thanks to Simen from another post [0], I just figured out
what the correct constructor and factory method for a template
wrapper should be:
https://run.dlang.io/is/S4vHzL
struct W(T) {
T val;
this(U : T, this This)(auto ref U val) {
this.val = val;
}
}
auto wrap(T)(auto ref T t) {
return W!T(t);
}
Seems to catch all cases!
[0]:
https://forum.dlang.org/thread/hxbeektmpnmfdbvjr...@forum.dlang.org
How come isMutable returns true for structs that cannot be modified
import std.traits: isMutable;
struct S {
immutable int i = 3;
}
pragma(msg, isMutable!S);
void main() {
S s;
s = S();
}
And is there a trait that takes the transitivity of immutability
in to account?
Cheers,
- Ali
Re: Moving druntime into the DMD repository
On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote: This a thread to explore whether it would be feasible to do so. What do you think? -- One is a compiler the other is a (optional!) library. merging the two means forcing druntime onto people who want to use dmd. the seperation of the repositories is a good thing, since it prompt people to think before breaking compatibilty with the runtime. Which _should_ not happen often anyhow! druntime and dmd are seperate things. - Has the dmd/druntime split being annoying you too? The split has never anonyned me. I find it to be helpful in fact. - Do you have a better suggestion? Yes, try to implement features in non-breaking, non runtime-dependent way. - Would this break your workflow in a drastic way? I'd have to see the effects, to be definite about this, but likely the answer is yes.
Re: Initialise non-copyable, non-default-constrauctable member struct
On Friday, 27 July 2018 at 13:05:07 UTC, aliak wrote: https://run.dlang.io/is/lLrUiq Sorry: https://run.dlang.io/is/20FUoj
Re: Moving druntime into the DMD repository
On Friday, 27 July 2018 at 12:04:18 UTC, Jonathan M Davis wrote: On Friday, July 27, 2018 5:03:50 AM MDT Seb via Digitalmars-d wrote: What do you think? -- - Has the dmd/druntime split being annoying you too? - Do you have a better suggestion? - Would this break your workflow in a drastic way? It would break all existing tools and scripts that are used to build the existing repos - many of which are not official tools. So, yes, it would be very annoying. That's not necessarily a good enough reason not to do it, but IMHO, it really needs to provide solid benefits to rearrange things like that for it to be worth breaking all of the existing tools that anyone uses for building dmd, druntime, and Phobos. Not necessarily. The druntime repo could just contain makefiles that forward to the dmd ones.
Re: Initialise non-copyable, non-default-constrauctable member struct
On Friday, 27 July 2018 at 12:11:37 UTC, Peter Particle wrote:
Question is related to this:
https://dlang.org/spec/struct.html#disable_default_construction
struct S {
int x;
@disable this(); // Disables default construction
@disable this(this); // Disable copying
this(int v) { x = v; }
}
struct T {
float y;
S s;
@disable this(); // Disables default construction
@disable this(this); // Disable copying
this(float v) {
y = v;
s = S(cast(int)v);// tried option 1
s.__ctor(cast(int)v); // tried option 2
}
}
Error: struct `S` is not copyable because it is annotated with
`@disable`
in both cases.
Is there some way around this problem?
This works on the latest dmd:
struct S {
int x;
@disable this(); // Disables default construction
@disable this(this); // Disable copying
this(int v) { x = v; }
}
struct T {
float y;
S s;
@disable this(); // Disables default construction
@disable this(this); // Disable copying
this(float v) {
y = v;
s = S(cast(int)v);
}
}
void main() {
auto s = T(3);
}
https://run.dlang.io/is/lLrUiq
[Issue 19119] App crashes with strange behavior of ctors/dtors from CPP
https://issues.dlang.org/show_bug.cgi?id=19119 --- Comment #7 from Vladimir Marchevsky --- Sounds logical. I've tried to additionally export Bar, map it in D and also to add Foo::a and Foo::b to mapping to make it full. Problem has gone and it seems to work correct without crashes or memory leaks. But how does it happen to work under some conditions before (like with non-virtual dtor)? Does "virtual" change used methods to create/delete objects somehow or was that sort of random luck?.. --
Re: An Optional!T and the implementation of the underlying type's opUnary
On Thursday, 26 July 2018 at 06:37:41 UTC, Simen Kjærås wrote:
On Wednesday, 25 July 2018 at 21:59:00 UTC, aliak wrote:
It needs to work with const as well and immutable too.
immutable a = 3;
auto b = -a; // is ok, should be ok with the optional as well.
Plus T can be a custom type as well with "some" definition of
opUnary. I can't seem to find any implementation guidelines
either so I assume opUnary or any of the ops implementation
details is implementation defined.
Template this[0] (and CopyTypeQualifiers[1])to the rescue!
Ah! Genius!
I had no idea that using TemplateThisParameters would not
necessitate qualifying the function in question either.
As for assigning to Optional!(immutable int), the language
basically forbids this (cannot modify struct with immutable
members). It would, as you say, cause problems when you can get
a pointer to the contents.
So is this undefined behaviour?
import std.stdio;
struct S(T) {
T value;
void opUnary(string op)() inout {
mixin(op ~ "cast(T)value;");
}
}
void main() {
immutable a = S!int(2);
++a;
}
Re: Looking for the article comparing D to Ada and others
On Wednesday, 25 July 2018 at 21:59:52 UTC, Ali Çehreli wrote: Somebody had posted an article here on how well different languages matched certain requirements of a certain coding safety standards. I remember D was doing pretty well and I think Ada (or SPARK?) was included as well. What article? Where? But you didn't meant https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrate-to-d/ This is about Pascal, Ada and D, but was heavily criticised because other languages were not considered after very early stage.
Re: Moving druntime into the DMD repository
On Friday, 27 July 2018 at 12:02:50 UTC, Russel Winder wrote: On Fri, 2018-07-27 at 11:03 +, Seb via Digitalmars-d wrote: This a thread to explore whether it would be feasible to do so. Motivation -- DRuntime and DMD heavily depend on each other. But DMD is only one of the compilers, there is LDC and GDC. Is Druntime unique to DMD or do the other compilers also use it? It's unique to the DMD Frontend which is used by LDC/GDC ;-) They use it with small modifications, e.g. for the LLVM intrinsincs and a few LDC specific features: https://github.com/ldc-developers/druntime https://github.com/dlang/druntime/compare/master...ldc-developers:ldc
Re: Moving druntime into the DMD repository
On Friday, 27 July 2018 at 12:04:18 UTC, Jonathan M Davis wrote: On Friday, July 27, 2018 5:03:50 AM MDT Seb via Digitalmars-d wrote: What do you think? -- - Has the dmd/druntime split being annoying you too? - Do you have a better suggestion? - Would this break your workflow in a drastic way? It would break all existing tools and scripts that are used to build the existing repos - many of which are not official tools. So, yes, it would be very annoying. FWIW I don't think this would be the case. All build scripts I have seen call the Makefile (except for LDC/GDC, of course). The Makefile build would continue to work at any stage. That's not necessarily a good enough reason not to do it, but IMHO, it really needs to provide solid benefits to rearrange things like that for it to be worth breaking all of the existing tools that anyone uses for building dmd, druntime, and Phobos. As mentioned, I don't know of any tool that builds druntime itself. Everyone calls the Makefiles. If there are tools that build druntime on their own, it would be a very good point yes. It also arguably makes no sense in that a lot of what's in druntime has nothing to do with dmd - e.g. all of the OS C bindings are in there. There are also several modules that need to be in druntime, because druntime uses them but don't really have much to do with the compiler (e.g. core.time and core.thread). And not only from a code organizational standpoint does the current separation make a lot of sense for a lot of what's in druntime, but it also matters from the standpoint of who has permissions to do what. Right now, it's reasonable to give privileges to folks to merge PRs for druntime who have no business merging PRs for dmd. If the repos are merged, then we're forced to either give some of those folks dmd merge rights or make the smaller pool of folks who have merge rights for dmd deal with those PRs. This shouldn't be a problem either as GitHub's CODEOWNERS files, are made for this use case and all we need would be sth. this: * @team-dmd src/druntime @team-druntime https://help.github.com/articles/enabling-required-reviews-for-pull-requests (Step 8) Also, given that druntime gets linked into Phobos, having that repo be part of the compiler is that much weirder. In that sense, it belongs more with Phobos than dmd. The dependencies between the three repos do occasionally cause problems, but overall, I think that the separation makes a lot of sense. It causes A LOT of problems in terms of maintaining the CI and build scripts, moving things between DMD and adding test for druntime features to the dmd testsuite.
Re: Blogpost about the T.init problem
On Monday, 23 July 2018 at 14:26:17 UTC, Nick Treleaven wrote: On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature wrote: To reproduce the format issue, try to print the struct with writefln!"%s"(MyDomainType()). I implemented the compile time format string checking by evaluating `format(fmtStr, Args.init)` at compile time and seeing if an exception was thrown. So the above problem could be worked around by guarding the invariant test with a check that CTFE is not active. Note that I've gotten a fix for this merged that doesn't break format use in ctfe: the compile time format string check simply writes into a NoOpSink, and the formattedWriter detects the NoOpSink and skips the toString. So that's good now.
Re: DIP Proposal: @manualScoped to prevent automatic field destruction
Update: https://github.com/dlang/dmd/pull/5830 Turns out unions with fields with destructors is **define behavior**. I did not know this. Probably the spec needs updating. So that pretty much alleviates the need for this DIP. Though I kind of half-believe that this DIP is actually *better* than unrestricted unions, so I'd still leave it open.
Initialise non-copyable, non-default-constrauctable member struct
Question is related to this:
https://dlang.org/spec/struct.html#disable_default_construction
struct S {
int x;
@disable this(); // Disables default construction
@disable this(this); // Disable copying
this(int v) { x = v; }
}
struct T {
float y;
S s;
@disable this(); // Disables default construction
@disable this(this); // Disable copying
this(float v) {
y = v;
s = S(cast(int)v);// tried option 1
s.__ctor(cast(int)v); // tried option 2
}
}
Error: struct `S` is not copyable because it is annotated with
`@disable`
in both cases.
Is there some way around this problem?
Re: Bizarre Memory leak issue ??? help!
On Friday, 27 July 2018 at 11:50:11 UTC, Mark wrote: On Friday, 27 July 2018 at 06:20:57 UTC, Stefan Koch wrote: On Friday, 27 July 2018 at 04:56:01 UTC, Mark wrote: Hello, ... Have you tried using -profile-gc ? No, I haven't. Ill give that a try and see what I find. Thanks! Hmm, unfortunately that only seems to work if the program ends. However, using handy writelns Im tracing the problem down to a section before all that code. Maybe I should have just slept on the problem. Thanks anyways!
Re: Moving druntime into the DMD repository
+1 leave it
Re: DIP Proposal: @manualScoped to prevent automatic field destruction
On Friday, 27 July 2018 at 11:44:10 UTC, aliak wrote: A) I'd suggest "@nodestruct" instead, since it sounds like that what it's supposed to do? Yes-ish, but it's also supposed to fill the hole in the typesystem created by T.init, and "you can only assign T.init to types marked @nodestruct" sounds kind of magic. B) is this basically for the case of invariants being run before destructors where T.init are not valid runtime instances of T? Yep, that's the reason I'm looking at it. C) If it is, then this seems to me that this is something that should just work without a programmer needing to know about how T.init and invariants are implemented, so an implementation that doesn't call invariants before a destructor only if an instance was never constructed at runtime is maybe the way to go? Though I have no idea how possible that is. Basically impossible without giving every type a hidden "bool initialized" field. So, basically impossible. The advantage of doing it with @manualScoped is twofold. First, it also covers the case of opAssign methods taking parameters that don't need to be destroyed at scope end. Second, even a constructor may return a T.init (and, for instance, increment a static variable), so if being T.init skipped the destructor we'd again get a constructor/destructor mismatch. @manualScoped makes it clear this is a variable that contains a value with a manually managed lifetime, so users take responsibility to call moveEmplace/destroy as required to make constructor/destructor calls match up, which is the goal. Basically, think of a @manualScoped variable as a "weak value" in analogy to weak references. Cheers, - Ali maybe your PR where invariants is not called before a destructor if an instance is a T.init is maybe the way to go? [0] The PR itself was just a way to hack around this. The problem isn't the invariant check on destruction, the problem is the destruction without the matching construction.
Re: Bizarre Memory leak issue ??? help!
See what the program does when it consumes memory.
Re: Moving druntime into the DMD repository
On Friday, July 27, 2018 5:03:50 AM MDT Seb via Digitalmars-d wrote: > What do you think? > -- > > - Has the dmd/druntime split being annoying you too? > - Do you have a better suggestion? > - Would this break your workflow in a drastic way? It would break all existing tools and scripts that are used to build the existing repos - many of which are not official tools. So, yes, it would be very annoying. That's not necessarily a good enough reason not to do it, but IMHO, it really needs to provide solid benefits to rearrange things like that for it to be worth breaking all of the existing tools that anyone uses for building dmd, druntime, and Phobos. It also arguably makes no sense in that a lot of what's in druntime has nothing to do with dmd - e.g. all of the OS C bindings are in there. There are also several modules that need to be in druntime, because druntime uses them but don't really have much to do with the compiler (e.g. core.time and core.thread). And not only from a code organizational standpoint does the current separation make a lot of sense for a lot of what's in druntime, but it also matters from the standpoint of who has permissions to do what. Right now, it's reasonable to give privileges to folks to merge PRs for druntime who have no business merging PRs for dmd. If the repos are merged, then we're forced to either give some of those folks dmd merge rights or make the smaller pool of folks who have merge rights for dmd deal with those PRs. Also, given that druntime gets linked into Phobos, having that repo be part of the compiler is that much weirder. In that sense, it belongs more with Phobos than dmd. The dependencies between the three repos do occasionally cause problems, but overall, I think that the separation makes a lot of sense. - Jonathan M Davis
Re: Moving druntime into the DMD repository
On Fri, 2018-07-27 at 11:03 +, Seb via Digitalmars-d wrote: > This a thread to explore whether it would be feasible to do so. > > Motivation > -- > > DRuntime and DMD heavily depend on each other. > But DMD is only one of the compilers, there is LDC and GDC. Is Druntime unique to DMD or do the other compilers also use it? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Bizarre Memory leak issue ??? help!
On Friday, 27 July 2018 at 06:20:57 UTC, Stefan Koch wrote: On Friday, 27 July 2018 at 04:56:01 UTC, Mark wrote: Hello, ... Have you tried using -profile-gc ? No, I haven't. Ill give that a try and see what I find. Thanks!
Re: DIP Proposal: @manualScoped to prevent automatic field destruction
On Friday, 27 July 2018 at 09:30:00 UTC, FeepingCreature wrote:
A new UDA is introduced: @manualScoped. It is valid for fields
in structs and classes, as well as variables and parameters.
Fields marked with @manualScoped are not automatically
destructed on scope end.
For instance, a function taking a struct as a @manualScoped
value will lead to a copy constructor call, but no destructor
call. It is assumed the passed value will be moved into another
field via move() or moveEmplace().
In @safe, only @manualScoped fields may be initialized with
.init. This is to indicate that init represents a hole in the
typesystem, and using it forces you to engage in manual
lifecycle management.
The goal of this DIP is to make the union hack unnecessary and
resolve the value/variable problem with .init initialized
struct destruction, where { S s = S.init; } led to a destructor
call but no corresponding constructor call.
Opinions?
A) I'd suggest "@nodestruct" instead, since it sounds like that
what it's supposed to do?
B) is this basically for the case of invariants being run before
destructors where T.init are not valid runtime instances of T?
C) If it is, then this seems to me that this is something that
should just work without a programmer needing to know about how
T.init and invariants are implemented, so an implementation that
doesn't call invariants before a destructor only if an instance
was never constructed at runtime is maybe the way to go? Though I
have no idea how possible that is.
Cheers,
- Ali
maybe your PR where invariants is not called before a destructor
if an instance is a T.init is maybe the way to go? [0]
Re: Moving druntime into the DMD repository
On 27 July 2018 at 13:32, Mike Franklin via Digitalmars-d wrote: > On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote: > >> What do you think? >> -- > > > Also, is there any other compelling reasons besides the test dependency > problem to motivate merging the two repositories? What other benefits would > it provide, if any? > > Mike I can't think of any, but such ABI breakages should be avoided. The preferred route for any such changes that require synchronisation between dmd and druntime should be in order of: 1. Commit new functions/feature to druntime as dead/unused code. 2. Commit changes to dmd which activates the feature you added to druntime. 3. Add/turn on tests in both dmd and druntime. Iain
Re: Moving druntime into the DMD repository
On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote: What do you think? -- Also, is there any other compelling reasons besides the test dependency problem to motivate merging the two repositories? What other benefits would it provide, if any? Mike
[Issue 19119] App crashes with strange behavior of ctors/dtors from CPP
https://issues.dlang.org/show_bug.cgi?id=19119 --- Comment #6 from anonymous4 --- Shouldn't you declare class fields on the D side? How one can determine how much memory to allocate for the instance? --
Re: Moving druntime into the DMD repository
On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote: - Do you have a better suggestion? Do we have a rich enough CI API to recognize dependencies between repositories? For example, if I create a local branch in my dmd repository named `fix_bug` and a local branch in my druntime repository also named `fix_bug` and submit both PRs to their corresponding repositories, can the CI scripts recognize that they have the same branch name and pull them both for testing? Mike
Re: Whence came UFCS?
On Friday, 27 July 2018 at 10:30:07 UTC, Jonathan M Davis wrote:
It evolved out of D's member function call syntax for arrays -
basically, for years before we had UFCS in D, we had UFCS for
arrays. However, when and how that was added to arrays, I don't
know. I don't recall it ever not being in the language, but I
never used D1, and I don't know if it had it. At minimum, it's
been in D since early D2, if not much earlier. I'd have to do a
lot of spelunking through old releases to figure out when it
was added.
Certainly, the origins of UFCS in D do not come from making it
possible to extend user-defined types with member functions. It
comes from wanting member function call syntax when using
arrays (probably aimed primarily at strings, but I don't know).
It's just that later it was proposed to extend it so that it
would work with any type and thus make the member function call
syntax universal.
This compiles in DMD 0.50 (oldest version on the download page,
nov 20, 2002), so I think it's safe to say it's been around for a
while:
void fun(int[] arr) {}
void main() {
int[] a;
a.fun();
}
Arrays' .reverse, .sort and others were added in 0.24, but I
can't find a download for anything before 0.50.
--
Simen
Moving druntime into the DMD repository
This a thread to explore whether it would be feasible to do so.
Motivation
--
DRuntime and DMD heavily depend on each other.
It happens very often that a PR needs to touch both and then a
complicated three-step (or sometimes four-step PR series) needs
to be done to keep the CIs happy.
Moreover, as the whole testsuite is at dmd, it happens more often
that an error is caught in the testsuite, but would require a
druntime PR or the opposite you make a PR to druntime and want
its accompanying test to be checked by the CI.
How would this happen?
--
A potential migration could look like this:
- lock druntime (e.g. only allowing admins to merge)
- move source code to dmd (of course with the git history, see
e.g. [1])
- update the druntime/posix.mak build script to forward to the
new source location
- update other dlang Makefiles
- remove everything else from druntime (optional check for the
Makefile update step)
- update CIs and build scripts (more on this below)
[1] https://stackoverflow.com/a/10548919/3026245
What would need to be updated?
-
- Makefiles for DMD, Druntime, Phobos, Tools, Dlang.org (mostly
path updates)
- LDC/GDC (I think LDC already includes druntime as git submodule)
If we update the druntime/posix.mak file to call the
druntime/posix.mak at its new location, then there would be zero
breakage (druntime already requires dmd to cloned) and over time
these can be updated:
- CI scripts (all of them explicitly clone druntime, but removing
that line should be all)
- Release scripts at dlang/installer
- Packager build scripts
(most distros just ship the the libphobos2.{so,a} libraries, but
if druntime is shipped too, it will require a path update for the
release after such a potential migration.)
What do you think?
--
- Has the dmd/druntime split being annoying you too?
- Do you have a better suggestion?
- Would this break your workflow in a drastic way?
Re: A struct with a tuple as alias this, is kind of confusing
On Friday, 27 July 2018 at 10:48:08 UTC, ag0aep6g wrote: On 07/27/2018 12:19 PM, Yuxuan Shui wrote: On Friday, 27 July 2018 at 10:17:21 UTC, Yuxuan Shui wrote: [...] Oh no, is it just defining arrays in the is() statement, though? Yup. But wait, this works: alias C = A!(1,2,3); static if (C[0] < C[1]) pragma(msg, "Ha!"); Looks like DMD decides that `C[0]` and `C[1]` can't be types in that situation, so it tries the alias this. That's in line with how alias this is supposed to work: only kick in when the code wouldn't compile otherwise. Let's just say this is confusing as hell.
Re: A struct with a tuple as alias this, is kind of confusing
On 07/27/2018 12:19 PM, Yuxuan Shui wrote:
On Friday, 27 July 2018 at 10:17:21 UTC, Yuxuan Shui wrote:
First, it surprised me that I can't index a struct like that. So:
struct A(T...) {
alias S = T;
alias S this;
}
alias B = A!(int, double);
B[0] x; // Actually an array
Then, it surprised me again, that I actually can index it, sometimes
static if (!is(B[0] == B[1]))
pragma(msg, "Works!");
Why is this language like this :(
Oh no, is it just defining arrays in the is() statement, though?
Yup.
But wait, this works:
alias C = A!(1,2,3);
static if (C[0] < C[1])
pragma(msg, "Ha!");
Looks like DMD decides that `C[0]` and `C[1]` can't be types in that
situation, so it tries the alias this. That's in line with how alias
this is supposed to work: only kick in when the code wouldn't compile
otherwise.
[Issue 19040] Quickbooks Enterprise Payroll Support Phone Number +1-888-740-5903
https://issues.dlang.org/show_bug.cgi?id=19040 devinsmith0786 changed: What|Removed |Added CC||devinsmith0...@gmail.com --- Comment #2 from devinsmith0786 --- While using QuickBooks Enterprise Payroll Software, a user faces a lot of issues and problems. This is when you need expert help. Therefore, we provide QuickBooks Enterprise Payroll Support Phone Number +1-888 980-6517. This is a toll free phone Number. Our Support team is accessible 24X7 for any kind of assistance to solve all errors and problems related to QuickBooks Software. --
[Issue 19120] Cannot slice a struct with a tuple alias this
https://issues.dlang.org/show_bug.cgi?id=19120
Yuxuan Shui changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX |---
--- Comment #2 from Yuxuan Shui ---
Actually, we can index that struct.
A revised example:
import std.meta;
struct A(T...) {
alias S = T;
alias S this;
}
alias X = A!(int, double);
alias Y = AliasSeq!((X)[0])[0]; // Fine
pragma(msg, Y); // int
alias Z = AliasSeq!((X)[0..$]); // Not fine?
--
Re: Whence came UFCS?
On Friday, July 27, 2018 03:41:29 Sameer Pradhan via Digitalmars-d wrote: > In the end I thought I might as well dump my thoughts on the D > forum and hear straight from the horse's (or horses') > mouth(s)---so to speak. It evolved out of D's member function call syntax for arrays - basically, for years before we had UFCS in D, we had UFCS for arrays. However, when and how that was added to arrays, I don't know. I don't recall it ever not being in the language, but I never used D1, and I don't know if it had it. At minimum, it's been in D since early D2, if not much earlier. I'd have to do a lot of spelunking through old releases to figure out when it was added. Certainly, the origins of UFCS in D do not come from making it possible to extend user-defined types with member functions. It comes from wanting member function call syntax when using arrays (probably aimed primarily at strings, but I don't know). It's just that later it was proposed to extend it so that it would work with any type and thus make the member function call syntax universal. - Jonathan M Davis
Re: A struct with a tuple as alias this, is kind of confusing
On Friday, 27 July 2018 at 10:17:21 UTC, Yuxuan Shui wrote:
First, it surprised me that I can't index a struct like that.
So:
struct A(T...) {
alias S = T;
alias S this;
}
alias B = A!(int, double);
B[0] x; // Actually an array
Then, it surprised me again, that I actually can index it,
sometimes
static if (!is(B[0] == B[1]))
pragma(msg, "Works!");
Why is this language like this :(
Oh no, is it just defining arrays in the is() statement, though?
But wait, this works:
alias C = A!(1,2,3);
static if (C[0] < C[1])
pragma(msg, "Ha!");
A struct with a tuple as alias this, is kind of confusing
First, it surprised me that I can't index a struct like that. So:
struct A(T...) {
alias S = T;
alias S this;
}
alias B = A!(int, double);
B[0] x; // Actually an array
Then, it surprised me again, that I actually can index it,
sometimes
static if (!is(B[0] == B[1]))
pragma(msg, "Works!");
Why is this language like this :(
[Issue 19120] Cannot slice a struct with a tuple alias this
https://issues.dlang.org/show_bug.cgi?id=19120 Yuxuan Shui changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Yuxuan Shui --- I just came into realization that it is not possible to index a struct with alias this tuple. This seems to be quite inconvenient. --
[Issue 19121] Indexing a struct with a tuple alias this doesn't give you the thing at given index
https://issues.dlang.org/show_bug.cgi?id=19121 Yuxuan Shui changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --
[Issue 19121] Indexing a struct with a tuple alias this doesn't give you the thing at given index
https://issues.dlang.org/show_bug.cgi?id=19121 --- Comment #1 from Yuxuan Shui --- No wait, so there is actually no way to index a struct with a tuple alias this? --
#dbugfix 16746 - Output Makefile-style depfiles for ninja and make
Hi! Since this issue came up again here just now, I would like to draw your attention to this particular bug. It hinders integration with widely used build systems like Automake, CMake, Meson and build tools like ninja/make and in general results in very suprising results especially when using templates in code that is split-built. A patch is available in a PR against dmd, but there was no new activity since last March, so it would be nice to get feedback and have the change finally merged in some form. Bug: https://issues.dlang.org/show_bug.cgi?id=16746 PR: https://github.com/dlang/dmd/pull/6961 Thank you and greetings from the Debian developer's conference in Taiwan (with more interest in D here than expected :-) ) Cheers, Matthias
[Issue 19121] New: Indexing a struct with a tuple alias this doesn't give you the thing at given index
https://issues.dlang.org/show_bug.cgi?id=19121
Issue ID: 19121
Summary: Indexing a struct with a tuple alias this doesn't give
you the thing at given index
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: yshu...@gmail.com
struct A(T...) {
alias S = T;
alias S this;
}
alias X = A!(int, double);
alias Y = X[0]; // Fine
pragma(msg, Y); // Not int ?!?!
// A!(int, double)[0] ???
Y y;
pragma(msg, typeof(y));
pragma(msg, is(typeof(y) == int)); // false ?!
--
DIP Proposal: @manualScoped to prevent automatic field destruction
A new UDA is introduced: @manualScoped. It is valid for fields in
structs and classes, as well as variables and parameters. Fields
marked with @manualScoped are not automatically destructed on
scope end.
For instance, a function taking a struct as a @manualScoped value
will lead to a copy constructor call, but no destructor call. It
is assumed the passed value will be moved into another field via
move() or moveEmplace().
In @safe, only @manualScoped fields may be initialized with
.init. This is to indicate that init represents a hole in the
typesystem, and using it forces you to engage in manual lifecycle
management.
The goal of this DIP is to make the union hack unnecessary and
resolve the value/variable problem with .init initialized struct
destruction, where { S s = S.init; } led to a destructor call but
no corresponding constructor call.
Opinions?
[Issue 19120] New: Cannot slice a struct with a tuple alias this
https://issues.dlang.org/show_bug.cgi?id=19120
Issue ID: 19120
Summary: Cannot slice a struct with a tuple alias this
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: yshu...@gmail.com
Right now if a struct has a tuple as its alias this, we could index it at
compile time, but not slicing it.
struct A(T...) {
alias S = T;
alias S this;
}
alias X = A!(int, double);
alias Y = X[0]; // Fine
alias Z = X[0..$]; // Not fine?
https://godbolt.org/g/phwQFo
--
Re: Hunt framework 1.2.0 released
On Tuesday, 17 July 2018 at 09:27:26 UTC, Brian wrote: Hello, hunt framework fix bugs version release. Major updates: 1. Add simplify functions 2. You can use createUrl() to create link url from module.controller.action 3. support date() / url() function for template engine 4. fix multi-domain use other port 5. use portgresql / mysql / sqlite on default config 6. upgrade dependencies package version to latest 7. release stabled skeleton project hunt-framework source code: https://github.com/huntlabs/hunt hunt-skeleton source code: https://github.com/huntlabs/hunt-skeleton Where can one get comprehrnsive tutorial in English for the Hunt framework?
[Issue 19119] App crashes with strange behavior of ctors/dtors from CPP
https://issues.dlang.org/show_bug.cgi?id=19119 --- Comment #5 from Vladimir Marchevsky --- Sorry if it's not useful, just want to point out couple of things from my perspective as language newcomer that may hint something for you: 1) Example in ticket works when Foo::~Foo is not virtual. So does in that case D know how to destroy CPP classes and is it "virtual" causing some troubles? 2) Example in ticket also works in other case - Foo::~Foo is virtual but Foo doesnt contain Bar. Why implementation details (Bar isnt even exported and mapped in D) do some changes to behavior? --
Re: Generated opAssign in the presence of a copy constructor
Why the memcpy? This looks inefficient. Is it in case the constructor throws? Have a 'nothrow' case where it constructs directly to this? The copy constructor must be called on an object in the initial state, so it cannot be called directly on this as it is already initialized. __dtor is used as a matter of demonstration. Indeed, xdtor is the the alias which points to the generated destructor (__dtor, __fieldDtor or __aggregatedDtor)
Re: Generated opAssign in the presence of a copy constructor
On Thu., 26 Jul. 2018, 9:35 am 12345swordy via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: > 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? It pointlessly default initialises immediately after destruction. I tried to suggest destruct() function in complement when I was fiddling with it for C++ recently. I think it would be very useful.
Re: Bizarre Memory leak issue ??? help!
On Friday, 27 July 2018 at 04:56:01 UTC, Mark wrote:
Hello,
I am building a toy compiler in D, and during this I ran into a
situation.
It involves checking the header of each function, going through
the arguments, and seeing if there is any duplicate identifiers.
I have a python script that feeds a whole bunch of source files
that have one error of a specific type each (with an expected
error).
The only file that causes this problem is called fnDupArgs.nerf
(I called my language nerf).
In my mind, this is a simple check, but for some reason that I
can't identify, it causes the entire computers memory to be
filled up, causing swapping on the hard drive!
Here is my project:
https://github.com/MarkTigchelaar/Nerf-Compiler-2.0
In system_test.py, that test is commented out (un comment it,
line 135)
the source of the problem is in the file analyze_semantics.d,
on line 36:
void add_func_args_to_local_variable_table(Function* func, ref
SymbolTable table) {
string[] func_args = func.arg_names.dup;
string[] arg_types = table.get_function_args(func.name);
if(func_args.length != arg_types.length) {
throw new Exception("Number of function variables is
not the
same as number of types for same
function."); <--compiler error
}
for(int i = 0; i < func_args.length; i++) {
table.add_local_variable(func_args[i], arg_types[i]);
<-- line 36
}
}
this calls the symbol tables method in the file symbol_table.d,
on line 129:
final void add_local_variable(string variable, string type)
{ <-- line 129
import fn_header_syntax_errors: duplicate_fn_args;
if(!is_declared_variable(variable)) {
variable_table[variable] = type;
variables_at_scope_level[scope_level] ~= variable;
} else {
duplicate_fn_args();
}
}
Now I've been staring at this for an hour and a half. If you
leave the one test commented out, everything passes, and all is
well.
But if you run that one extra test, it tries to swallow up all
the available memory on the computer.
I genuinely have 0 clue why this is happening, could someone
help?
If I can't figure this one out, my compiler will have a hole in
it's semantic checking that I don't want.
Thanks!
Have you tried using -profile-gc ?
