Re: Beta 2.108.0
On Saturday, 16 March 2024 at 09:26:20 UTC, Iain Buclaw wrote:
The RC for 2.108 has been released, which includes the
following changes from the initial beta:
- Named Arguments is now implemented and documented as a new
feature in this release. The beta supports the feature, but was
left undocumented while some remaining issues were being fixed.
- Hexstrings now implicitly convert to integer arrays. The
beta had introduced support to allow casting to arrays only.
http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.108.0.html
As usual please report any bugs at
https://issues.dlang.org
-Iain
on behalf of the Dlang Core Team
```d
union U
{
float asFloat;
uint asInt;
}
auto u0 = U(1.0); // this sets the `asFloat` field
auto u1 = U(asInt: 0x3F80); // formerly not possible
```
Wow, this is so cool, can't wait to try it out, thanks to
everyone who made it happen!
Re: Adding Modules to C in 10 Lines of Code
On Monday, 6 June 2022 at 05:49:55 UTC, Paulo Pinto wrote: On Sunday, 5 June 2022 at 22:41:14 UTC, Walter Bright wrote: On 6/4/2022 10:54 PM, Paulo Pinto wrote: That paper had a real implementation to follow along, I didn't see it. while Lucid and IBM products were real things one could buy. That are *C* compilers doing imports for *C* code? What C compilers have imports: gcc - nope clang - nope VC - nope Digital Mars C - nope C Standard - nope ImportC - yes! https://clang.llvm.org/docs/Modules.html And I am out of this thread. https://clang.llvm.org/docs/Modules.html#objective-c-import-declaration "At present, there is no C or C++ syntax for import declarations. Clang will track the modules proposal in the C++ committee. See the section Includes as imports to see how modules get imported today." So Object-C can import C, but *C* cannot import *C*. Walter added __import support in *.c, clang could have done the same but they *didn't*, they were also probably just 10 lines away from the goal.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote: On Sunday, 6 February 2022 at 10:55:20 UTC, Daniel N wrote: Guess I'm way too late, I just find it very strange you settled on mixedCase, it's not used for anything else. (nothrow @nogc). I also don't agree with the motivation that @use is hard to search for because @ is an unusual symbol. @mustUse is a user-defined attribute, and the official style guide says that names of UDAs should be camelCased: https://dlang.org/dstyle.html#naming_udas "Hard to search for" in this context means "hard to Google for", not "hard to grep for". Search engines tend to ignore symbols like @. If you just google for "dlang attributes" you should be able to find what you search for, regardless of what it is called, thus personally I think greppability is the only thing we have to cater for. If the attribute is in core or truly built-in feels like an implementation detail, if nogc was created today, it also probably would have been listed in core.attribute. By using a different naming convention we actually block refactoring/cleanup of the frontend by moving build-in attributes to the core.attribute. However by choosing "use" we could avoid the entire discussion about which case to use... Best Regards, Daniel N
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Thursday, 3 February 2022 at 17:25:16 UTC, Paul Backus wrote: On Friday, 28 January 2022 at 13:07:13 UTC, Mike Parker wrote: Congratulations to Paul Backus. DIP 1038, "@mustUse" has been accepted after he implemented changes to address concerns from Walter. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md Update for anyone following this: a PR implementing DIP 1038 has been submitted, and is currently awaiting Walter's approval. https://github.com/dlang/dmd/pull/13589 Guess I'm way too late, I just find it very strange you settled on mixedCase, it's not used for anything else. (nothrow @nogc). I also don't agree with the motivation that @use is hard to search for because @ is an unusual symbol. Both these suggestions are better imho. @use @mustuse Still congratulations, I guess the most important part is that we get the feature... I'm just very surprised, is all.
Re: styx, a programming languange written in D, is on the bootstrap path
On Thursday, 14 January 2021 at 17:51:51 UTC, Basile B. wrote: This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. I'd like to thank the D compiler developers, that let me work on DMD even if I borrow another path. [1] : https://gitlab.com/styx-lang/styx Love the design FWIW.
Re: Release D 2.094.0
On Saturday, 26 September 2020 at 22:12:17 UTC, Imperatorn wrote: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Hurrah! Yay! "-preview=in" is beyond epic!
Re: Release D 2.086.0
On Tuesday, 7 May 2019 at 15:13:05 UTC, Andrea Fontana wrote:
import std;
void main()
{
std.file.write("/tmp/test", "hello");
}
How should I fix this?
import std;
import file = std.file;
void main()
{
file.write("/tmp/test", "hello");
}
Re: Sublime Text Syntax Definition Rewrite
On Thursday, 28 February 2019 at 06:54:32 UTC, Benjamin Schaaf wrote: On Thursday, 28 February 2019 at 05:37:42 UTC, Dmitry wrote: On Thursday, 28 February 2019 at 00:30:24 UTC, Benjamin Schaaf wrote: I've recently gotten a massive rewrite of the D syntax ... Cool, thank you so much, much appreciated!
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Saturday, 9 February 2019 at 01:31:05 UTC, H. S. Teoh wrote:
Using lowering to lambdas as a way of defining semantics is not
the same thing as actually using lambdas to implement a feature
in the compiler!
While it can be convenient to do the latter as a first stab,
I'd expect that the optimizer could make use of special
knowledge available in the compiler to implement this more
efficiently. Since the compiler will always use a fixed pattern
for the lowering, the backend could detect this pattern and
optimize accordingly. Or the compiler implementation could
lower it directly to something more efficient in the first
place.
T
The lambda even correctly handles "@disable this(this);", I like
it!
struct One { @disable this(this); }
void fun(ref One one) { }
One gun() { return One.init; }
void main()
{
One one; one.fun();
(One __temp0){ return fun( __temp0 ); }(gun()); // OK
}
Re: [OT] LLVM 5.0 released - LDC mentioned in release notes
On Friday, 8 September 2017 at 08:40:13 UTC, Brian wrote: On Thursday, 7 September 2017 at 21:14:24 UTC, bpr wrote: On Thursday, 7 September 2017 at 20:55:22 UTC, Nordlöw wrote: Are there any new code-generation features in LLVM 5.0 that LDC will make use of? Given that LLVM has direct support for coroutines since 4.0 (https://llvm.org/docs/Coroutines.html) I've wondered if D (even just LDC D for starters) could use that to implement async/await or a similar feature. C++17 is supported it? Clang 5 supports C++17 and "C++ coroutines TS" http://releases.llvm.org/5.0.0/tools/clang/docs/ReleaseNotes.html
Re: static foreach is now in github master
On Tuesday, 18 July 2017 at 06:48:29 UTC, Jacob Carlborg wrote: On 2017-07-17 20:14, Andrei Alexandrescu wrote: For those who want to play with our new static foreach feature and are willing to take the steps to building their own dmd, the feature is now merged in master: https://github.com/dlang/dmd/pull/6760 Happy hacking! That was quick, and awesome :) Great work to Timon and everyone else involved. wow! Now, just how am I supposed to be able to work today (using C) and not play with this pure awesomeness?!
Re: A New Import Idiom`
On Tuesday, 14 February 2017 at 02:32:33 UTC, Jerry wrote:
On Monday, 13 February 2017 at 22:40:55 UTC, Ali Çehreli wrote:
On 02/13/2017 06:28 AM, Mike Parker wrote:
https://www.reddit.com/r/programming/comments/5tt33y/a_new_import_idiom_for_d/
I claimed there is a performance improvement in compilation.
Can someone answer kibwen's question on this subthread please:
https://www.reddit.com/r/programming/comments/5tt33y/a_new_import_idiom_for_d/ddp6a4p/
Ali
I ran it a couple of times and just doing the following has a
faster compile time:
import std.datetime : SysTime;
import std.traits : isIntegral;
No difference in binary size as the article stated either,
using dmd.
Anyways yes this is kind of cool and fascinating how it works,
but that aside I hope I never see this used in phobos. Does
anyone else feel this way?
I suspect you test something slightly different, I tested both on
linux and windows, with dmd, ldc and gdc(not on windows).
time dmd slow.d
time dmd fast.d
== Slow ==
import std.datetime : SysTime;
import std.traits : isIntegral;
void func(T)(SysTime a, T value) if (isIntegral!T)
{
import std.stdio : writeln;
writeln(a, value);
}
void main() {}
== Fast ==
template from(string moduleName)
{
mixin("import from = " ~ moduleName ~ ";");
}
void func(T)(from!"std.datetime".SysTime a, T value) if
(from!"std.traits".isIntegral!T)
{
import std.stdio : writeln;
writeln(a, value);
}
void main() {}
Re: A New Import Idiom`
On Monday, 13 February 2017 at 16:17:49 UTC, jmh530 wrote: So I tried it again comparing all three versions on my machine. This time I didn't notice a difference in compilation speed or binary size between the version with import std.datetime; import std.traits; and the one with import std.datetime : SysTime; import std.traits : isIntegral; So I'm not sure it matters. Cool, thanks for checking!
Re: A New Import Idiom`
On Monday, 13 February 2017 at 15:00:24 UTC, jmh530 wrote: On Monday, 13 February 2017 at 14:28:20 UTC, Mike Parker wrote: Daniel Nielsen put together a post describing the import idiom that came to light in a recent forum discussion regarding DIP 1005 [3]. The relevant links are at [1] and [2]. [1] https://dlang.org/blog/2017/02/13/a-new-import-idiom/ [2] https://www.reddit.com/r/programming/comments/5tt33y/a_new_import_idiom_for_d/ [3] https://forum.dlang.org/thread/tzqzmqhankrkbrfsr...@forum.dlang.org?page=1 A great post. With the Jack Stouffer comparison, wouldn't it be fairer to do: import std.datetime : Systime; import std.traits : isIntegral; Probably, please help measuring your idea and post it here. I intentionally chose a test made by someone else to avoid biasing from my part. It was the only test I found at time of writing.
Re: LDC 1.0.0 has been released!
On Monday, 6 June 2016 at 10:45:39 UTC, Guillaume Piolat wrote: very nice! how about a howto for windows/VS users? 1) Download LDC unpack anywhere 2) Download VisualD install https://github.com/dlang/visuald/releases 3) Setup VisualD to find LDC Tools->Options->Projects and Solutions->Visual D Settings->LDC Directories ... Profit!
Re: foo => "bar" key/value literals in D!
On Wednesday, 25 May 2016 at 11:22:41 UTC, Jacob Carlborg wrote: On 2016-05-25 11:24, Daniel N wrote: ParameterIdentifierTuple can hopefully be updated to take advantage of this feature when it's available in compiler without requiring to change the API of ParameterIdentifierTuple. [1] https://github.com/dlang/dmd/pull/5201 Issue9608 is good too, but insufficient. import std.traits; static assert(__traits(isTemplate, a => 0)); static assert(!__traits(isTemplate, (int a) => 0)); The 2nd case can't be solved by 9608 since it's about introspecting templates and "(int a) => 0)" is no template.
Re: foo => "bar" key/value literals in D!
On Tuesday, 24 May 2016 at 01:33:40 UTC, Adam D. Ruppe wrote: On Monday, 23 May 2016 at 20:08:11 UTC, Daniel N wrote: This pull request just removes an intentional restriction and make this feature more easily accessible for meta-programming, so that not everyone has to reinvent the wheel in their own libraries. S I'm actually not entirely convinced on that change. Parameter names should *not* be part of a function pointer or delegate type From an end-user perspective I find it reasonable to expect that an API which takes lambda:s works consistently for both below examples. i.e. if we support one we should support the other. [1] fun!( x => y) [2] fun!((int x) => y) Currently I just copy/paste the fix to ParameterIdentifierTuple everywhere as the needed primitives already exist. Removing the already existing primitives now is imho too late, as it breaks code, which sometimes is OK, but this time there's no clear solution how to rewrite the broken code. Unfinished Library based Named-parameters proof-of-concept: (yes, I know. It needs to be updated to handle case [2]) https://dpaste.dzfl.pl/ae55de677f86 /vote open floodgates for introspection, capitalizing on the strengths of D.
Re: foo => "bar" key/value literals in D!
On Monday, 23 May 2016 at 19:00:40 UTC, Adam D. Ruppe wrote: Have I gone completely mad?!?! That makes two of us, I also use similar techniques. Please help argue in favour of pulling this: https://github.com/dlang/phobos/pull/3620/files https://issues.dlang.org/show_bug.cgi?id=13780 This pull request just removes an intentional restriction and make this feature more easily accessible for meta-programming, so that not everyone has to reinvent the wheel in their own libraries.
Re: Visual D 0.3.43 released - better support for VS 2015
On Saturday, 28 November 2015 at 09:14:03 UTC, Rainer Schuetze wrote: Hi, there is a new release of Visual D available at http://rainers.github.io/visuald/visuald/StartPage.html This time there is no major new feature to announce, but quite a few improvements to * VS 2015 support * building with LDC * configuration dialogs * C++ to D conversion wizard See http://rainers.github.io/visuald/visuald/VersionHistory.html for the complete list of changes and the version history. Visual D is a Visual Studio extension that adds D language support to VS2005-2015. It is written in D, its source code can be found on github: https://github.com/D-Programming-Language/visuald. Rainer Thanks, works great. Only some minor issues: Some of the GUI optimization options doesn't propagate correctly to ldc. inline: no effect boundscheck: no effect singleobj: no gui option available and without it, the performance of my app is abysmal, that's how I noticed these issues. Optimization levels: only one level is exposed in the GUI Fortunately the workaround is easy, adding this to "additional options": -O5 -inline -boundscheck=off -singleobj Daniel N
Re: Fastest JSON parser in the world is a D project
On Saturday, 17 October 2015 at 08:07:57 UTC, Martin Nowak wrote: On Wednesday, 14 October 2015 at 07:35:49 UTC, Marco Leise wrote: - Data size limited by available contiguous virtual memory Mmaping files for sequential reading is a very debatable choice, b/c the common use case is to read a file once. You should at least compare the numbers w/ drop_caches between each run. It's a sensible choice together with appropriate madvise().
Re: Beta D 2.068.0-b1
On Thursday, 25 June 2015 at 14:04:57 UTC, Steven Schveighoffer wrote: On 6/25/15 6:34 AM, Martin Nowak wrote: if it wasn't in master when we merged master into stable it won't be part of the release. I was much hoping for: https://github.com/D-Programming-Language/dmd/pull/3998 I even thought it would make 2.067 but... guess there's no exceptions to the rule.
Re: dfix 0.1.1
On Tuesday, 28 October 2014 at 01:29:32 UTC, Brian Schott wrote: No. Really. I'm serious. https://github.com/Hackerpilot/dfix dfix is a tool for automatically upgrading older D syntax to the newer style. * Updates old-style alias syntax to new-style * Fixes implicit concatenation of string literals * Automatic conversion of C-style array declarations and parameters to D-style. * Upgrades code to comply with DIP64 if the --dip64 switch is specified. (You probably don't want to use this) * Upgrades code to comply with DIP65 unless the --dip65=false switch is specified. Awesome, would be nice if it was included with the default install for 2.067+
