Re: Release D 2.109.0
On Sunday, 2 June 2024 at 15:51:04 UTC, Iain Buclaw wrote: Glad to announce D 2.109.0, ♥ to the 44 contributors. This release comes with 15 major changes and 26 fixed Bugzilla issues, including: Thanks! I've written a changelog entry about reinterpreting a byte as bool being unsafe: https://github.com/dlang/dmd/pull/16560 I hope it's OK to update the online changelog with that.
Re: Release D 2.108.0
On Wednesday, 3 April 2024 at 08:39:03 UTC, Ferhat Kurtulmuş wrote: On Tuesday, 2 April 2024 at 21:15:16 UTC, Nick Treleaven wrote: Official docs: https://dlang.org/spec/istring.html Things like: Can it be used in nogc code? etc. Yes, the literal is just a value sequence. Thank you. It looks like run.dlang.org is not using the last dmd version yet. Yes, it's DMD64 D Compiler v2.105.3. I wanted to make the examples runnable in that page but we need a dmd update there. I also noticed the 'dmd-nightly' version is v2.103.0!
Re: Release D 2.108.0
On Tuesday, 2 April 2024 at 19:41:52 UTC, Ferhat Kurtulmuş wrote: Could you please provide a link to the documentation that one should read to know everthing related to string interpolation in dlang. Official docs: https://dlang.org/spec/istring.html Things like: Can it be used in nogc code? etc. Yes, the literal is just a value sequence.
Re: DConf Online Livestream Link
On Monday, 18 March 2024 at 11:33:08 UTC, Andrea Fontana wrote: https://github.com/dlang/dconf.org/tree/master/2024/online/slides Thanks!
Re: DConf Online Livestream Link
On Sunday, 10 March 2024 at 16:07:23 UTC, Mike Parker wrote: The countdown is on! I'll kick off the DConf Online Livestream at 14:55 UTC on March 16. You can find it here: https://www.youtube.com/live/8GV_TuYk3lk And if you haven't seen the details yet, take a look here: https://dconf.org/2024/online/index.html See you there! This was great, interesting selection of talks. BTW each link to slides is giving me a 404. Luckily the live stream video is still up to rewind :-)
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Wednesday, 6 December 2023 at 16:28:08 UTC, Mike Parker wrote: One way to do that in D is to use `alloca`, but that's an issue because the memory it allocates has to be used in the same function that calls the `alloca`. So you can't, e.g., use `alloca` to alloc memory in a constructor, and that prevents using it in a custom array implementation. You can call `alloca` as a default argument to a function. The memory will be allocated on the caller's stack before calling the function: https://github.com/ntrel/stuff/blob/master/util.d#L113C1-L131C2 I've just tested and it seems it works as a constructor default argument too.
Re: Evolving the D Language
On Sunday, 9 July 2023 at 18:51:01 UTC, IchorDev wrote: On Friday, 7 July 2023 at 13:19:51 UTC, Nick Treleaven wrote: Changing the syntax just for an obsolete feature would send the wrong message. [...] cent and ucent are already an error as of 2.100. Were they even implemented? Clearly you're not looking at this the same way as me, [or Walter](https://github.com/dlang/dmd/pull/15393). Fixing old code isn't the only upside to resurrecting old features. I thought Walter was asking for features that should be changed from deprecated to obsolete, it seems I was wrong. First thing, I think all languages should support binary, octal, decimal and hexadecimal literals as a baseline. Octal is probably the least important of them, but can still be plenty useful in its own right. Generally programmers can count in binary and decimal, hex somewhat. Not octal. You technically don't need *any* numerical literals at all in D, you could make all of them with string-to-number templates. You could take such an approach to just about everything in D, actually! On the other hand, people working on low-level Linux code might be pretty appalled to find out that they can't simply use octal literals to represent file permissions in D. Maybe because they're used to working in languages that don't have D's CTFE abilities. Octals are still rare. There are other literals, not all literals can be supported in the language. So the better solution for less common literals is to embrace the library pattern and dogfood it. C++ has user-defined literal support. D doesn't need that. ... There are a few D features that were poorly implemented (or not implemented at all), and then simply removed instead of being fully reconsidered. You might say that for many, they were indeed reconsidered, and then added to Phobos instead. Now some of these features pre-date BetterC, of course, but I am a regular BetterC user. A feature being moved to Phobos translates to "you don't get to use this in most of your code anymore" for me. `octal` could have been added to druntime, or you can copy the code. For betterC there's probably quite a lot of stuff in Phobos that works with betterC, so that is a general problem. I'm not a user of complex or imaginary types, but I don't see why they needed to be removed from D, were they a huge burden to maintain compared to being in Phobos? It depends whether you value language simplification and dogfooding.
Re: Evolving the D Language
On Friday, 7 July 2023 at 10:57:57 UTC, IchorDev wrote: Hexstring literals, They were first deprecated on Mar 01, 2018: https://dlang.org/changelog/2.079.0.html#hexstrings And removed in 2.086, so it's probably unlikely that any maintained code is using them. complex and imaginary floating point types & the corresponding literals, Deprecated in 2.097, maybe a good candidate to obsolete instead. built-in 128-bit integer types, cent and ucent are already an error as of 2.100. Were they even implemented? and octal literals, I think could all be added back to D without causing much detriment to D users who don't want to use them. ... 2. Ideally octal literals would have a better syntax. (e.g. "0o123") Changing the syntax just for an obsolete feature would send the wrong message. People rarely use octal so it doesn't need to be in the language, library is enough. The C syntax is indeed bug prone - leading zero.
Re: Evolving the D Language
On Friday, 7 July 2023 at 10:45:33 UTC, Guillaume Piolat wrote: alias this was a relatively bad idea, even if an iconic feature. I don't remember people from outside the community being impressed by alias this. There was no way to rewrite the code without breaking dependent code. That should not happen with a routine compiler release. We have the right to backtrack on bad ideas instead of keeping them forever. Marking a feature as obsolete doesn't mean it has to be supported forever. Presumably at some point support will be dropped. Possibly obsolete features could become deprecations before they are actually removed. The current deprecation system is very good. For something like alias this in classes, making it obsolete instead of deprecated signals that the feature won't be removed in 20 months (based on a 2-month release cycle, 10 release deprecation cycle as standard).
Re: D Contributor Tutorials Part 1 - Building the Compiler From Source - Windows
On Sunday, 22 January 2023 at 12:51:53 UTC, Nick Treleaven wrote: sppn.exe src\core\stdc\errno.c -HIsrc\importc.h -ED -oerrno.i -I. Error: C preprocess command sppn.exe failed for file src\core\stdc\errno.c, exit status 1 failed launching sppn.exe src\core\stdc\errno.c -HIsrc\importc.h -ED -oerrno.i -I. Turned out dmc wasn't correctly installed. I downloaded dmc.zip which fixed it. But chrome says 'Your connection is not private' and won't let me download that even if I look under Advanced. I also tried curl: ``` curl: (60) SSL: no alternative certificate subject name matches target host name 'ftp.digitalmars.com' Fixed by updating & using Firefox.
Re: D Contributor Tutorials Part 1 - Building the Compiler From Source - Windows
On Sunday, 8 January 2023 at 11:27:14 UTC, Mike Parker wrote: In this first tutorial of the series, he gives an overview of what happens when compiling a D source file, then shows how to set up an environment from which to build dmd and the standard library/runtime binary. The next video will use this setup to start making changes to dmd. Thanks, this is great (for posix builds). However I'm not sure the Windows instructions in the video are correct. It is good Dennis mentioned to use DM make as the wiki only mentioned that for the VS build instructions (I have updated it to make it clear). I tried running `make -f win32.mak` from the phobos root and got this: ``` Error: don't know how to make '../dmd/druntime/lib/druntime.lib' ``` So it seems on Windows druntime still does have to be built before that (unlike on Linux). So I ran `make -f win32.mak` from dmd/druntime and got this error: ``` ..\compiler\..\generated\windows\release\32\dmd -c -of=errno_c_32omf.obj -m32omf -conf= -O -release -preview=dip1000 -preview=fieldwise -preview=dtorfields -inline -w -Isrc -Iimport -v -P=-I. src\core\stdc\errno.c predefs DigitalMars LittleEndian D_Version2 all Windows Win32 CRuntime_DigitalMars CppRuntime_DigitalMars D_InlineAsm D_InlineAsm_X86 X86 D_ModuleInfo D_Exceptions D_TypeInfo D_HardFloat D_Optimized binary..\compiler\..\generated\windows\release\32\dmd.exe version v2.101.0-rc.1-72-g5c3dafa06f config DFLAGS(none) include src\importc.h sppn.exe src\core\stdc\errno.c -HIsrc\importc.h -ED -oerrno.i -I. Error: C preprocess command sppn.exe failed for file src\core\stdc\errno.c, exit status 1 failed launching sppn.exe src\core\stdc\errno.c -HIsrc\importc.h -ED -oerrno.i -I. ``` I don't know what `sppn.exe` is. --- Before trying phobos win32.mak I also tried the win64.mak but it needs `cl.exe` which apparently I can get here: https://ftp.digitalmars.com/bup.zip But chrome says 'Your connection is not private' and won't let me download that even if I look under Advanced. I also tried curl: ``` curl: (60) SSL: no alternative certificate subject name matches target host name 'ftp.digitalmars.com' More details here: https://curl.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. ```
Re: D Contributor Tutorials Part 1 - Building the Compiler From Source
On Sunday, 8 January 2023 at 19:28:59 UTC, ryuukk_ wrote: The Wiki is outdated and mentions tools that do not exist https://wiki.dlang.org/Building_under_Windows I haven't been able to build druntime on Windows. I have just updated the page to make it clear that DM make is needed even when not using Visual Studio. Which tools does it mention that don't exist? I updated it with the little information i had but that still wasn't enough to be able to build the whole thing I even asked on the forum for some help, wich was met with silence https://forum.dlang.org/thread/aapqglgpugyuimhof...@forum.dlang.org?page=1 Well some people replied, but it didn't really help.
Re: DIP 1043---Shortened Method Syntax---Accepted
On Saturday, 24 September 2022 at 08:45:33 UTC, Dukc wrote: On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker wrote: The fact that the feature was already implemented behind a preview switch carried weight with Atila. He noted that, if not for that, he wasn't sure where he would stand on adding the feature, but he could see no reason to reject it now. If there is no reason to reject an already-implemented feature, there's no reason to to reject it as non-implemented either. Not just already implemented, but reviewed and merged by existing maintainers. It shows the feature was considered by trusted colleagues to be worth adding as a preview. If it feels like it's too much work to implement an otherwise good DIP, it should be accepted on the condition that someone does it, not rejected IMO. DIPs for semantic features are much easier to review when there's an implementation so people can play with the feature and see how it interacts with the existing language. Basically the burden should be on the advocates to make their case, not on the maintainers to investigate an idea.
Re: Beta 2.099.0
On Tuesday, 15 February 2022 at 13:06:47 UTC, Martin Nowak wrote:
http://dlang.org/changelog/2.099.0.html
Thanks. Regarding:
https://dlang.org/changelog/2.099.0.html#allow_casting_from_typetuple_to_typetuple
I don't understand why this is allowed:
```d
alias Tuple(T...) = T;
void foo()
{
Tuple!(int, int) tup;
auto foo = cast(long) tup;
pragma(msg, typeof(foo)); // (int, int)
}
```
Casting 2 values to one type is weird, and why does it not affect
the result type?
https://github.com/dlang/dmd/pull/13501#discussion_r808203393
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Tuesday, 12 January 2021 at 17:27:50 UTC, Q. Schroll wrote: On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote: Gotcha. I think I would use that more than the current DIP (though I prefer [1]s to [1]$). You can do it today if you don't mind putting the marker in front: https://run.dlang.io/is/E6ne4k (Its operator abuse. What would you expect?) Cool. I'd call it F for fixed size array, `F[e1,e2]`.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Monday, 11 January 2021 at 20:25:14 UTC, Luhrel wrote: I think if the DIP proposed a literal syntax instead of a new variable declaration syntax, it would be much less of a burden to the compiler. I think we don't have any partial (variable) type inference syntax ATM. I don't think that will be complicated to implement, the compiler already says "mismatched array lengths, 2 and 1". Ok, you're right. I still think a literal syntax is the more natural way to do this though.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 13 January 2021 at 14:48:07 UTC, Atila Neves wrote: Why do they have to scroll to the top? They don't, you're right. But if you want to use it throughout the module you need a top-level import, by convention at the top. Also the convention seems to be to put a local import at the start of a scope rather than sandwiched in the middle of statements. Even if they did, what editor are they using that they can't jump back to where they were? Geany. You can set a marker but probably the editor should automatically add to location history before the go to start of file key binding is executed.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Monday, 11 January 2021 at 13:05:18 UTC, jmh530 wrote: On Monday, 11 January 2021 at 12:32:42 UTC, Nick Treleaven wrote: [snip] I think if the DIP proposed a literal syntax instead of a new variable declaration syntax, it would be much less of a burden to the compiler. I think we don't have any partial (variable) type inference syntax ATM. [snip] Could you provide an example? (apologies if you already have...) Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto var =` with it as normal.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Monday, 11 January 2021 at 12:32:42 UTC, Nick Treleaven wrote:
```
int[2] bar() { return [1,2]; }
long[$] a6 = bar(); // implicit conversion
static assert(is(typeof(a6) == long[2]));
```
Error: cannot implicitly convert expression `bar()` of type
`int[2]` to `long[]`
This is the error you get today if you write `long[2]` for the
type of a6. (It's a bit confusing that `long[]` slice type is
mentioned in the message).
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Friday, 8 January 2021 at 14:07:29 UTC, Luhrel wrote:
Example a3 is straightforward the primary use case for
staticArray:
auto a3 = [1,2,3].staticArray;
I really don't like the `.staticArray` because it's
non-esthetic. I don't know if it's really argument, mainly
because it's very personal.
The worst thing about it is you have to import std.array, so
probably people won't bother scrolling to the top to add the
import and losing/bookmarking their place, and will just count
the items themselves. When it was originally proposed, it was in
object.d.
I think if the DIP proposed a literal syntax instead of a new
variable declaration syntax, it would be much less of a burden to
the compiler. I think we don't have any partial (variable) type
inference syntax ATM.
Correct. I'll rewrite this example.
There should be a type conversion:
```
int[2] bar() { return [1,2]; }
long[$] a6 = bar(); // implicit conversion
static assert(is(typeof(a6) == long[2]));
```
Error: cannot implicitly convert expression `bar()` of type
`int[2]` to `long[]`
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 18:33:54 UTC, Dukc wrote:
```
int[$] bar(int[2] arr) // Error: not allowed in
functions declarations
{
return arr ~ [3, 4];
}
```
causes an error if the return type is specified as int[4].
Why? `arr` is static so the compiler should be able to figure
that no overflow will ever happen.
Because:
1. concatenation with a static array is not defined (use `arr[]`).
2. slices do not implicitly convert to a static array.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 18:29:05 UTC, Nick Treleaven
wrote:
Can be fixed (probably with another name):
//import std.array;
Actually template overloading seems to work fine:
template staticArray(T) {
T[n] staticArray(ulong n) (auto ref T[n] a) {return a;}
}
T[n] staticArray(T, ulong n) (auto ref T[n] a) {return a;}
void main(){
auto a = [1,2,3].staticArray!float;
pragma(msg, typeof(a)); // float[3]
a.writeln();
[1,2,3].staticArray.writeln();
}
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 18:14:42 UTC, Luhrel wrote:
It works only for the `int` type and above (and other types as
structs).
example with short:
---
extern(C) void main()
{
import std.array;
auto a = [0, 1].staticArray!short; // error
}
Can be fixed (probably with another name):
//import std.array;
import std.stdio;
void main(){
auto a = [1,2,3].staticArray!float;
pragma(msg, typeof(a)); // float[3]
a.writeln();
}
template staticArray(T) {
T[n] staticArray(ulong n) (auto ref T[n] a) {return a;}
}
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
From the feedback thread:
On Wednesday, 6 January 2021 at 17:54:34 UTC, Dukc wrote:
`std.array.staticArray` can already handle most of the problems
described, and it does work in betterC - I just tested with LDC
1.20.1 targeting WebAssembly. while there are remaining cases
(`auto fun(int[$] = [1,2,3])` isn't easy to represent now), I
suspect they are a bit too trivial to justify a new feature.
Type inference for parameters with a default argument could be
made to work.
auto fun(auto a = [1,2,3].staticArray) {return a;}
On to refining the feature if it's accepted anyway. This should
work:
```
int[$] bar(int[2] arr) // Error: not allowed in
functions declarations
{
return arr ~ [3, 4];
}
```
Why? because you can use `auto` as return type. `Type[$]`
should IMO work anywhere `auto` does.
The inferred return type is int[], and causes an error if the
return type is specified as int[4].
You need to mention that this DIP will break code in this,
admittedly rare, case:
```
int[] x = something;
int y = something[0 .. staticArrFunc(cast(int[$])[1,2,3])];
```
Excellent point, but it isn't just casts, anywhere you use a type
(template instantiation) that is within an indexing expression
will have this problem.
I wonder if `$` should be allowed inside an expression, like
this:
```
int[$+2] a = [1,2,3]; //static array of [1,2,3,0,0]
```
Not worth it, easy to workaround.
Re: New language based on D
On Wednesday, 18 November 2020 at 00:58:40 UTC, dangbinghoo wrote: both of them uses keyword `interface`, and "Interfaces describe a list of functions that a class that inherits from the interface must implement". shows these may not work with betterC. Pretty sure tardy only uses an interface definition for compile time introspection (probably the same goes for open-methods). The instance of Polymorphic doesn't convert to any interface type or Object.
Re: From the D Blog: A Pattern for Head-mutable Structures
On Thursday, 25 June 2020 at 13:17:55 UTC, jmh530 wrote: Good piece. I've been following the recent thread, but this really helped make some things clear. Do you have a link to that thread (or title) please?
Re: Beta 2.093.0
On Wednesday, 24 June 2020 at 21:01:05 UTC, Martin Nowak wrote: http://dlang.org/changelog/2.093.0.html Thanks. BTW The list of bug fixes and enhancements seems to be missing.
Re: DIP 1028 "Make @safe the Default" is dead
On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
On 5/29/2020 2:07 AM, Timon Gehr wrote:
It would be great if `@safe:` did not affect declarations that
would otherwise infer annotations.
The idea is the simple, general rule that:
attribute declaration;
attribute { declaration; }
attribute: declaration;
behave the same way.
To preserve this, then please can we have `@safe module foo;`.
This would change the default on a module basis to @safe, but
still infer e.g. function template bodies as @system where
necessary. This feature would allow modules from different
projects, including ones written before this feature would be
added can coexist happily. There would be no breakage, unlike DIP
1028 (which I BTW would support at a lower preference than the
above feature, apart from unmarked extern(C) declarations being
@safe).
Re: now it's possible! printing floating point numbers at compile-time
On Saturday, 22 December 2018 at 20:08:12 UTC, Stefan Koch wrote: I came across a short and efficient implementation[0] of the grisu2 algorithm for converting floating point numbers into strings. Which I then ported into CTFEable D code. Thus enabling you to convert doubles into strings at compiletime. Great! Is the MIT license compatible with Boost? If so I suggest we include it in Phobos. I remember Andrei was calling for a Grisu port for CTFE some years ago, but I think licensing of non-D implementations at the time was an issue.
Re: Blogpost about the T.init problem
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.
Re: Blog post on automem
On Thursday, 4 May 2017 at 08:41:55 UTC, Atila Neves wrote: I took a look at this. It's a druntime problem. Unique.~this calls std.experimental.allocator.dispose, which calls destroy in object.d which calls rt_finalize: extern (C) void rt_finalize(void *data, bool det=true); Notice the lack of `@nogc` in the declaration. Adding the annotation should fix the problem, assuming the implementation is in fact `@nogc`. I'll file a bug and PR to fix it. Bug: https://issues.dlang.org/show_bug.cgi?id=17297
Re: Vision document for H1 2017
On Friday, 13 January 2017 at 12:53:16 UTC, Nick Treleaven wrote: On Friday, 13 January 2017 at 05:33:07 UTC, Chris Wright wrote: On that topic, D's arrays would play nicer with both refcounting *and* modern garbage collectors if they were structured as base, offset, length instead of start, length. That might be slower sometimes as slices wouldn't fit in two registers then. Although for custom data structures, offset & length could often share one register. Then the magic looking up of the base address can be avoided, saving time.
Re: Vision document for H1 2017
On Friday, 13 January 2017 at 05:33:07 UTC, Chris Wright wrote: On that topic, D's arrays would play nicer with both refcounting *and* modern garbage collectors if they were structured as base, offset, length instead of start, length. That might be slower sometimes as slices wouldn't fit in two registers then. You could put metadata just before the start of the array, including the reference count. Yes, but GC arrays already do that with GC metadata (alloc size) without having offset, so that technique could in theory be done with RC too. It's a bit mysterious how the base address is found, would be nice to have some clear docs on this to point to.
Re: Vision document for H1 2017
On Thursday, 12 January 2017 at 09:54:08 UTC, Mark wrote: I think the "D for C++ programmers" page could use a revamp: https://dlang.org/cpptod.html At the moment it mainly explains where and how D differs from C++. Whoever reads it may be ready to write C++ code in D, but this seems pointless and may give the impression that D is just C++ with a different syntax plus a few minor features (strong typedef and the scope statement). The page doesn't mention D's dynamic arrays, associative arrays, ranges, UFCS, function attributes and so on). It's intended to help C++ programmers switch to D, not as a comparison. It also links to: https://dlang.org/ctod.html which does mention arrays and various other small things. (I noticed some minor things to fix and submitted a pull request). One idea on my mind is providing various (honest, not specifically tailored) examples of C++ code that aims to solve a certain problem, and how the same problem can be solved in D in a better way (in some sense). I've seen this done effectively with Java vs. Scala. Sounds good. I think this thread is for big issues that need core focus though, anyone here can and should submit documentation.
Re: Release D 2.072.0
On Monday, 31 October 2016 at 07:27:50 UTC, Ali Çehreli wrote:
Is the only valid remaining use for the comma operator the
'for' loop iteration?
for ( ; ; ++i, ++j) {
// ...
}
Are there other uses?
The changelog shows it can be used for an expression statement:
// This is okay, the result is not used.
if (!mc)
mc = new MyContainerClass, mc.append(new Entry);
I've made a pull to improve the comma examples, e.g. adding
brackets (mc = ...), mc.append and removing unnecessary
statements:
https://github.com/dlang/dlang.org/pull/1502
Would be good if someone could review and merge.
Re: DIP1000: Scoped Pointers
On Thursday, 18 August 2016 at 17:05:05 UTC, Dicebot wrote:
On 08/11/2016 04:38 PM, Sönke Ludwig wrote:
That will just leave one hole in conjunction with the @trusted
destructor, which is (presumably) not easy to fix without much
larger changes to the type system, as well as to how container
types are built. It is still vulnerable to artificial
shortening of the elements' lifetime, e.g. by using opAssign()
or destroy():
@safe {
RefCountedSlice!int s = ...;
scope int* el;
el = [0];
s = RefCountedSlice.init;
*el = 12; // oops
}
I asked Walter about this in more details and right now plan is
to address it in a separate DIP that provides more integration
between reference counting and compiler. Within DIP1000 terms
such destructor must not be marked as @safe - essentially, it
will only enable @safe usage of stack allocated data in its
initial form.
I think RefCountedSlice can have a @trusted destructor so long as
opAssign is @system. (I'll likely make a PR to the DIP soon).
Re: C#7 features
On Friday, 6 May 2016 at 23:51:59 UTC, Steven Schveighoffer wrote:
Of COURSE D supports local ref variables:
struct RefVar(T)
{
private T * var;
this(ref T v) { var = }
auto get() { return *var; }
alias this get;
}
ref get() return {...
Which is unsafe even if the ctor is marked trusted, the struct
could be moved to a higher scope. But like in another thread, you
can have a ref property in @safe code:
T v;
@property ref myRef(){return v;}
So why are ref locals disallowed? Now we have the return
attribute on functions that take myRef by ref, can it still
escape?
ref myRef = v;
Re: let (x,y) = ...
On 19/02/2015 04:38, thedeemon wrote: int x, y, z, age; string name; let (name, age) = getTuple(); // tuple let (x,y,z) = argv[1..4].map!(to!int); // lazy range let (x,y,z) = [1,2,3]; // array SomeStruct s; let (s.a, s.b) = tuple(3, piggies); Alternatively std.typetuple.TypeTuple can be used instead of let: http://forum.dlang.org/post/op.wa4vn6lgsqugbd@localhost If a range or array doesn't have enough elements, this thing will throw, and if it's not desired there's let (x,y,z)[] = ... variant that uses just the available data and keeps the rest variables unchanged. With these functions you can skip certain elements: http://forum.dlang.org/post/jjnmh2$27o5$1...@digitalmars.com
Re: let (x,y) = ...
On 19/02/2015 17:00, Nick Treleaven wrote: Alternatively std.typetuple.TypeTuple can be used instead of let not for ranges and arrays though Yes, but `tuple` overloads could be added for those. Or not - the length isn't known at compile-time. Tuple already supports construction from a static array: int a, b; TypeTuple!(a, b) = Tuple!(int, int)([3, 4]); I'm hacking std.typecons so this does work: TypeTuple!(a, b) = [4, 5].tuple;
Re: let (x,y) = ...
On 19/02/2015 14:59, John Colvin wrote: On Thursday, 19 February 2015 at 13:52:29 UTC, Nick Treleaven wrote: On 19/02/2015 04:38, thedeemon wrote: int x, y, z, age; string name; let (name, age) = getTuple(); // tuple let (x,y,z) = argv[1..4].map!(to!int); // lazy range let (x,y,z) = [1,2,3]; // array SomeStruct s; let (s.a, s.b) = tuple(3, piggies); Alternatively std.typetuple.TypeTuple can be used instead of let not for ranges and arrays though Yes, but `tuple` overloads could be added for those. Tuple already supports construction from a static array: int a, b; TypeTuple!(a, b) = Tuple!(int, int)([3, 4]);
Re: Digger 1.0
On 01/10/2014 04:51, Vladimir Panteleev wrote: On Tuesday, 30 September 2014 at 12:19:05 UTC, Nick Treleaven wrote: On 23/09/2014 11:20, Nick Treleaven wrote: Linking phobos.lib is the first time I've got OOM, I use Firefox heavily. phobos.lib is only 10 MB, which is why I thought it odd that linking uses well over 1 GB. I'm now building Phobos 'myself' with win32.mak rather than with Digger, and it seems to use under 1 GB (~750 KB). YMMV. Here I meant 750 MB :-/ Also I think I was wrong to say just 'linking', it seems to be compiling Phobos as well, so it's understandable why it uses that amount of memory. I don't think Digger should use much more memory than when building things manually. Can you check what's using up memory when using Digger? With both Digger 1.0 and just win32.mak, building latest phobos.lib took about 792 MB. Sorry for the noise.
Re: Digger 1.0
On 23/09/2014 11:20, Nick Treleaven wrote: Linking phobos.lib is the first time I've got OOM, I use Firefox heavily. phobos.lib is only 10 MB, which is why I thought it odd that linking uses well over 1 GB. I'm now building Phobos 'myself' with win32.mak rather than with Digger, and it seems to use under 1 GB (~750 KB). YMMV. Also I think I was wrong to say just 'linking', it seems to be compiling Phobos as well, so it's understandable why it uses that amount of memory.
Re: Digger 1.0
On 22/09/2014 19:59, Vladimir Panteleev wrote: Firefox requires 4GB of memory to build. Chromium requires 8GB of memory to build. Android requires 16GB of memory to build. Thanks for the info, I didn't realize. If you want to work on big projects, you WILL need a decent computer. I think 4GB for a modern programming language's implementation is not an unreasonable requirement, even if it could be brought down in the future. Especially considering that you can't even buy a new laptop today with less than 4GB of RAM, and 3GB is becoming the norm for smartphones. OK. Perhaps I can upgrade my RAM (I can't afford a new computer). Linking phobos.lib is the first time I've got OOM, I use Firefox heavily. phobos.lib is only 10 MB, which is why I thought it odd that linking uses well over 1 GB.
Re: Digger 1.0
On 21/09/2014 18:43, Rainer Schuetze wrote: I tried it on Windows and Digger does an amazing job at installing dependencies. I think we should recommend it as the first thing to run when trying to get your hands on building dmd/phobos. +1 In case someone starts creating patches: Would it be possible to also write a batch file into the repository folder to redo a build of dmd, druntime and phobos without checking all the dependencies? Sometimes my Windows machine with 2 GB RAM gets OOM when trying to link phobos.lib (I have to close most programs and start again), it would be nice if there was a way to continue a failed build without starting from scratch. I also hope there's a way of making the link take less memory, perhaps by making sub-libraries first and linking those together. How about running the test suite? AFAICT the test suite needs a separate MSYS install from the one Git uses, e.g. for a newer version of 'diff'. Not sure if that makes it harder for Digger to support.
Re: DCD v0.4.0-beta1
On 22/09/2014 10:35, Brian Schott wrote: https://github.com/Hackerpilot/DCD/releases/tag/v0.4.0-beta1 Changelog at the above link. Let me know if and how you manage to break it by filing an issue on Github. I found this link to explain what DCD is ;-) https://github.com/Hackerpilot/DCD/blob/master/README.md The D Completion Daemon is an auto-complete program for the D programming language.
Re: D 2.066 is out. Enjoy!
On 19/08/2014 08:21, Jacob Carlborg wrote: Did someone finish the changelog? One thing missing is a Note on compiler conversions for unique expressions, like: https://github.com/D-Programming-Language/phobos/pull/2109/files#diff-0baf0d34bf308dc66e131c0e56e4239bR761
