On Monday, 3 July 2017 at 15:48:26 UTC, Petar Kirov [ZombineDev]
wrote:
but can you explain exactly what part of Rust's type system
provides extra
benefits in terms of optimization over D's type system?
In safe Rust, a reference to mutable data has to be unique [1].
So the optimizer could
On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:
* Drop the GC or at a minimum make it opt-in. Add a borrow
checker, automatic reference counting, or some other GC
alternative that doesn't require a separate thread.
AIUI D's GC doesn't use a separate thread:
On Sunday, 11 June 2017 at 00:28:58 UTC, Andrei Alexandrescu
wrote:
https://github.com/dlang/phobos/pull/5461
There's many good advantages to this. The immediate one is the
constraint is better structured and easier to understand. Then,
the compiler can print the exact clause that failed,
On Friday, 26 May 2017 at 21:31:20 UTC, Steven Schveighoffer
wrote:
Part of this may mean clarifying what @nogc actually means.
Does it mean no interaction with the GC system, or does it mean
"cannot run a collection cycle"?
I was pleased to find GC.addRange is now @nogc, so it seems
On Saturday, 3 June 2017 at 14:59:38 UTC, Jacob Carlborg wrote:
Would it be reasonable for the compiler to check for duplicated
keys in an associative array literal where all the keys are
known at compile time? For example:
auto aa = ["foo": 1, "foo": 1];
On Saturday, 20 May 2017 at 09:35:34 UTC, Stanislav Blinov wrote:
On Saturday, 20 May 2017 at 02:25:45 UTC, Walter Bright wrote:
void foo(scope string s);
string s = callCAPIAndAllocateString();
foo(s ~ "abc");
What will happen? The compiler will generate different code?
Won't compile?
On Saturday, 20 May 2017 at 02:05:21 UTC, Jonathan M Davis wrote:
What we would probably need would be to change msg is a
function which generates a message so that derived classes can
override that rather than passing a message string.
Further to Moritz's reply showing the existing toString
On Tuesday, 16 May 2017 at 11:20:57 UTC, Stanislav Blinov wrote:
On Tuesday, 16 May 2017 at 09:04:32 UTC, Nick Treleaven wrote:
The problem with this approach is all the work required to
convert existing code to use this style.
...
That's not a problem. In cases where compiler-provided
On Saturday, 13 May 2017 at 14:41:50 UTC, Stanislav Blinov wrote:
template types(args...) {
static if (args.length)
alias types = AliasSeq!(typeof(args[0]),
types!(args[1..$]));
else
alias types = AliasSeq!();
}
...
foreach(i, T; types!args) {
typeof(args) ;-)
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
On Saturday, 22 April 2017 at 11:56:31 UTC, Nick Treleaven wrote:
If I compile the above I get:
Deprecation: switch case fallthrough - use 'goto default;' if
intended
IMO the compiler should issue this warning with the OP's code.
https://issues.dlang.org/show_bug.cgi?id=7390#c4
On Friday, 21 April 2017 at 19:17:32 UTC, Adam D. Ruppe wrote:
Then realize that it does exactly the same thing when it is
inside a switch... it always breaks the innermost thing, which
happens to be this loop. (note that cases are not `breaked`,
the switch is.)
By coincidence I ran into
On Thursday, 20 April 2017 at 20:43:35 UTC, H. S. Teoh wrote:
If you're doing internationalization, though, neither option is
a good one (I gave an example using dates in another post):
printf-style formats have ordering issues (is it year first,
then month, then day? Or month first then day
On Thursday, 20 April 2017 at 21:34:44 UTC, Steven Schveighoffer
wrote:
Dmitry's solution is superior I think:
$"{a} times 3 is {a * 3}"
->
AliasSeq!(a, " times 3 is ", a * 3)
+1, this is more flexible.
Would work fine with writeln.
Yep, and std.conv.text. We might want a function that
On Thursday, 20 April 2017 at 19:02:20 UTC, Kagamin wrote:
Also how various kinds of strings would work?
r$"{can}\i\has{slashes}"
$`same {here}`
r"" and `` are WysiwygStrings. Interpolation is not WYSIWYG.
$"" would need to support escaping of the interpolation start
character, so may as
On Friday, 21 April 2017 at 08:36:12 UTC, Nick Treleaven wrote:
Converting from char types -> integers, whilst (arguably) bug
prone, at least is numerically sound. So perhaps we could
disallow uint -> dchar, which is unsound.
That is in the general case - when VRP can prove an integer fits
On Thursday, 20 April 2017 at 11:05:00 UTC, Nick Treleaven wrote:
On Wednesday, 19 April 2017 at 14:50:38 UTC, Stanislav Blinov
wrote:
Because integrals implicitly convert to characters of same
width (byte -> char, short -> wchar, int -> dchar).
Despite char.min > byte.min, char.max <
On Wednesday, 19 April 2017 at 14:50:38 UTC, Stanislav Blinov
wrote:
Because integrals implicitly convert to characters of same
width (byte -> char, short -> wchar, int -> dchar).
Despite char.min > byte.min, char.max < byte.max. Anyway,
appending an integer is inconsistent because
This bug is fixed as the code no longer segfaults but throws
instead:
https://issues.dlang.org/show_bug.cgi?id=5995
void main(){
string ret;
int i = -1;
ret ~= i;
}
Why is it legal to append an integer?
On Wednesday, 19 April 2017 at 00:08:19 UTC, Walter Bright wrote:
There are additional problems, such as:
$"{a} in %s {b}"
% should be escaped: "%s in %%s %s". There would be no use for a
single % otherwise.
and positional parameters:
$"{a} in {0}"
That would be literal 0: `"%s
On Thursday, 13 April 2017 at 05:29:28 UTC, Dukc wrote:
The reason it needs:
{ scope Object ob = new RefCountableType("foo");
scope ob2 = ob;
ob = new RefCountableType("bar");
}
The "foo" instance would leak if the destruction would be done
by calling at end of scope.
I assume you
On Tuesday, 11 April 2017 at 11:08:34 UTC, Dukc wrote:
This idea could be generalized:
-DRuntime would add an interface "ReferenceCountable".
-Throwable would implement it.
-When a new expression of ReferenceCountable type is used to
assign to a scope variable or argument, it's guaranteed to
On Tuesday, 4 April 2017 at 13:30:47 UTC, Meta wrote:
On Tuesday, 4 April 2017 at 08:38:32 UTC, Walter Bright wrote:
http://dlang.org/phobos/std_algorithm_iteration.html#.fold
Not quite the same as this is a fold over a TypeTuple/AliasSeq.
You could of course do:
only(args).fold!"a + b"()
On Saturday, 11 March 2017 at 19:28:16 UTC, H. S. Teoh wrote:
So the idea is to analyse the format string at compile-time to
determine exactly what functionality is actually used, and
instantiate only that. Think of it as a format-string
mini-compiler: given a format string and a list of
On Friday, 10 March 2017 at 19:02:06 UTC, H. S. Teoh wrote:
A long-standing item on my todo list is to implement
compile-time writefln format strings using this technique.
Yes, the actual checking seems straightforward - here I
implemented CT format as an overload:
import std.format :
On Thursday, 9 March 2017 at 20:54:23 UTC, Nick Sabalausky
(Abscissa) wrote:
On 03/08/2017 04:34 PM, H. S. Teoh via Digitalmars-d wrote:
auto parseFile(Slice)(Slice input)
if (isRandomAccessRange!Slice && hasSlicing!Slice &&
is(ElementType!Slice :
On Friday, 10 March 2017 at 01:10:21 UTC, H. S. Teoh wrote:
On Fri, Mar 10, 2017 at 01:07:33AM +, XavierAP via
Digitalmars-d wrote:
The web reference tersely says under its *Slice* Operator
Overloading chapter [1]: "To overload a[], simply define
opIndex with no parameters."
Should not
On Sunday, 19 February 2017 at 01:53:58 UTC, Timothee Cour wrote:
Doesn't add indentation:
with (module_!"std.stdio, std.traits")
void fun(T)(File input, T value)
if (isIntegral!T);
* what is the implementation of `module_` ? `from` defined
earlier doesn't allow for multiple modules as in
On Friday, 17 February 2017 at 04:09:14 UTC, timotheecour wrote:
* with(module_!"std.foo") is useful for scoping imports to
cover several declarations and being DRY; at the expense of
adding indentation/nesting and less nice syntax
Doesn't add indentation:
with (module_!"std.stdio,
On Wednesday, 15 February 2017 at 20:09:46 UTC, Timothee Cour
wrote:
This thread completely diverged from the original post, which
was propsing `::` instead of `from!`:
```
void fun(T)(std.stdio::File input, T value) if
(std.traits::isIntegral!T)
{...}
```
instead of:
```
void
On Thursday, 9 February 2017 at 05:40:01 UTC, Jonathan M Davis
wrote:
auto func(alias pred, R)(R range)
if(from!"std.range.primitives".isInputRange!R &&
is(typeof(pred(range.front)) == bool))
{...}
but you can't import std.range.primitives.front to make dynamic
arrays work, whereas
On Thursday, 2 February 2017 at 20:37:32 UTC, Random D user wrote:
What if d had a -safe-defaults switch? It should be ok, since
safe is stricter than unsafe right?
Yes, we need this because module-level '@safe:' doesn't allow
inferrence of @system.
This way old/existing code would compile
On Tuesday, 31 January 2017 at 18:21:02 UTC, Jack Stouffer wrote:
On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright
wrote:
2. The return value is derived from s1.
4. Copies of s1 or s2 are not saved.
Actually I didn't know either of those things from looking at
the signature because
On Saturday, 14 January 2017 at 15:30:42 UTC, Rainer Schuetze
wrote:
In addition, you need to lookup the pool anyway to figure out
if the pointer points to non-managed memory (stack, global
data, malloc'd memory).
Makes me wonder about a GC'd language where each pointer is
actually a member
On Tuesday, 17 January 2017 at 18:22:06 UTC, Nordlöw wrote:
https://github.com/dlang/phobos/pull/5038
This makes (at least) UnsignedTypeOf unused in Phobos, and it's
undocumented but public. There are LREFs in the std.traits docs
under the SomethingTypeOf section - none of these links go
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,
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
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
On Tuesday, 20 December 2016 at 18:51:05 UTC, Brad Anderson wrote:
Could the comma expression be contextually removed?
Specifically in return expressions as discussed initially in
this post?
Back in May a change was introduced to issue a deprecation
message for uses of the comma operator
On Saturday, 3 December 2016 at 16:37:21 UTC, Jerry wrote:
Also "string" is just an alias of an array,
"immutable(char)[]". So an array should have "front" defined.
Can you post more code?
You still have to `import std.range.primitives : front`, even for
arrays.
On Friday, 25 November 2016 at 17:21:52 UTC, Nick Treleaven wrote:
I've started documenting it now, will post a PR soon.
https://github.com/dlang/dlang.org/pull/1519
On Thursday, 24 November 2016 at 00:35:39 UTC, TheGag96 wrote:
The thing that gets me more is "return" as a function
attribute. I see it under "MemberFunctionAttribute" in the
grammar but I can't find an explanation for its use anywhere...
I've started documenting it now, will post a PR soon.
On Sunday, 20 November 2016 at 13:19:41 UTC, qznc wrote:
For mobile I would prefer it to use the whole width for the
title and convert the other two columns into "subtitle text"
below.
+1, that'd avoid the other columns taking up too much empty
vertical space vs. if the title column was
On Sunday, 6 November 2016 at 05:07:10 UTC, Andrei Alexandrescu
wrote:
if (auto variable = fun(); variable != 42) {
...
}
Why does the word "variable" need to appear twice? It seems
simpler to allow punctuation around existing syntax:
// possible future D
if ((auto variable = fun()) != 42)
On Friday, 4 November 2016 at 13:56:57 UTC, Andrea Fontana wrote:
If you don't like indentation you can simply ignore it or you
can use old goto :)
{
int i = someFunc();
if (i < 0) goto outer;
// your code here
}
outer:
BTW there is a trick to avoid goto+label:
switch (true) {
On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei
Alexandrescu wrote:
In order to make opAssign safe, a language change will be
necessary.
Technically, it should be possible with runtime checks:
https://forum.dlang.org/post/aeeffshzkfjbrejzt...@forum.dlang.org
The checking overheads
On Friday, 28 October 2016 at 11:53:16 UTC, Nick Treleaven wrote:
In the unittest, using with(Color) should help, but I couldn't
get that to compile (visit thinks invalid lambdas are being
passed).
https://issues.dlang.org/show_bug.cgi?id=16655
On Tuesday, 25 October 2016 at 13:04:22 UTC, ag0aep6g wrote:
On 10/25/2016 05:17 AM, Jacob wrote:
There's no editing one's
comments so I often see people making multiple posts to
themselves to
add more information or to correct themselves. That's just a
minor
issue.
I don't think that's
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
On Monday, 24 October 2016 at 04:14:52 UTC, Nick Sabalausky wrote:
It's just...I mean, yea, it works, and you could probably DRY
it up a little with a type contructing template ("alias
RgbColor = DoMagic!RgbColor_"), but...meh...
I think the following should be better. Instead of Proxy we
On Saturday, 22 October 2016 at 17:11:26 UTC, ag0aep6g wrote:
How is it guaranteed that `a` doesn't have side effects? May be
a function call, since empty parentheses can be omitted in
calls.
I missed that case. (Insert grumble about non-UFCS parenthesis
omission being allowed).
The
On Friday, 21 October 2016 at 15:26:12 UTC, mogu wrote:
[1,2,3].fold!((a, b) => a + b).writeln;
=>
[1,2,3].fold!{a, b => a + b}.writeln;
Probably (a, b => a + b) could be legal. Reasoning:
1. a could be an existing symbol in scope, otherwise it's an
undefined identifier error.
2. If a was
On Sunday, 16 October 2016 at 16:07:19 UTC, Nick Treleaven wrote:
I think this example is a bit awkward for D newbies to
decipher. I think here we are showing D's ctRegex; dropping the
functional map and lambdas would make this more universally
understood.
On Sunday, 16 October 2016 at 16:07:19 UTC, Nick Treleaven wrote:
// Chain functions together to round a string parsed as a real
number
alias roundString = pipe!(to!real, std.math.round, to!string);
In fact if we're just printing the rounded numbers, we can drop
to!string and inline
On Thursday, 13 October 2016 at 19:06:26 UTC, Karabuta wrote:
// Replace anything that looks like a real
// number with the rounded equivalent.
stdin
.byLine
.map!(l => l.replaceAll!(c => c.hit.round)
(reFloatingPoint))
On Wednesday, 5 October 2016 at 19:45:20 UTC, Basile B. wrote:
In this case let's drop completely the contracts...you can put
them in the body, at the beg or at the end...
Language support for contracts enables a super class to enforce
contracts on its virtual methods.
On Tuesday, 27 September 2016 at 10:55:47 UTC, John Colvin wrote:
but we don't (yet) have catch else, which is harder to
immitate. Options are:
A) the else clause is nothrow (in which case it can just go
last inside the try)
or
B) store a flag and have to use immitation finally:
{
On Wednesday, 28 September 2016 at 21:00:00 UTC, Steven
Schveighoffer wrote:
Moreover, Idan's suggestions about scope sharing make sense to
me and I
don't think his line of thinking would be compatible with
doing it the
way you suggest.
Declaring variables that you need in the right scopes
On Sunday, 18 September 2016 at 12:16:54 UTC, Andrei Alexandrescu
wrote:
I don't see that as much of a hurdle seeing as any template
written has a few "obvious" types it'll work with. To
encapsulate that if needed:
struct Awesome(A, B, C)
{
private enum ut = is(A == int) && is(B == int)
On Saturday, 17 September 2016 at 17:22:52 UTC, Andrei
Alexandrescu wrote:
///
static if (is(T == int)) unittest
{
Awesome awesome;
awesome.awesome;
}
}
The unittest documentation is nicely generated. The unittest
code itself is only generated for one
On Wednesday, 7 September 2016 at 11:20:18 UTC, Lodovico Giaretta
wrote:
I guess the only thing you can ask and obtain here (I mean,
with a bug report) is that @disable this() should be allowed to
coexist with static opCall(). That would prevent your users
from instantiating structs the wrong
On Wednesday, 7 September 2016 at 15:15:03 UTC, John Colvin wrote:
python3 uses / for floating point division and // for integer.
I really like the distinction, although I would prefer if / was
disallowed on integer operands entirely, i.e. 3/2.0 is ok but
3/2 is not, that would be an error and
On Monday, 5 September 2016 at 15:50:31 UTC, Lodovico Giaretta
wrote:
On Monday, 5 September 2016 at 15:43:43 UTC, Nick Treleaven
wrote:
We can already (almost do that):
import std.stdio, std.typecons;
void unpack(T...)(Tuple!T tup, out
On Thursday, 25 August 2016 at 14:43:35 UTC, Dominikus Dittes
Scherkl wrote:
(int, int, int, string) fn()
{
return (3, 2, 1, "meins");
}
int x, y, z;
string s;
(x, y, z, s) = fn();
Another solution is to support out argument declarations, as they
are a more general feature. These could
On Friday, 2 September 2016 at 11:18:58 UTC, Nick Treleaven wrote:
RCRef increments *RCSlice.count on construction and decrements
on destruction, but first checks that *count is > 1. If this
fails, an AssertError is thrown. When -noboundschecks is
passed, the code assumes no safety checks
On Friday, 2 September 2016 at 11:42:57 UTC, rikki cattermole
wrote:
I've got a much more advanced memory management solution[0].
I'm waiting on DIP1000 implementation before implementing it
into it.
But over all I quite like this type approach.
[0]
Hi,
I've been working on a proof of concept Reference Counted Slice
container, based on the one in DIP1000. That one now has opAssign
marked @system, see:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#owning-containers
So I decided to make an RCSlice with a @safe opAssign (and
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
On Thursday, 11 August 2016 at 21:57:06 UTC, Walter Bright wrote:
On 8/11/2016 6:36 AM, Marc Schütz wrote:
4) The DIP doesn't address mutable aliasing at all. As a
consequence, the
example `RefCountedSlice` is unsafe:
auto arr = RefCountedSlice!int(10);
auto ptr = [5];
arr =
On Monday, 25 July 2016 at 07:33:25 UTC, Yuxuan Shui wrote:
Valgrind reports double free anyways. I think it's just the
inaccuracy of the glibc double free detection.
Please file a bug - thanks!
https://issues.dlang.org/
I found this, maybe related:
On Friday, 22 July 2016 at 01:54:28 UTC, Yuxuan Shui wrote:
auto b = alloc.makeArray!A(10, A(1));
auto c = alloc.makeArray!A(2, A(2));
I noticed (using dpaste) if you edit the 'b' line to only
allocate 5 structs, and it won't crash. 6 or more, crash. Maybe a
On Sunday, 19 June 2016 at 02:06:59 UTC, deadalnix wrote:
Long story short, I need structs that do not move. I'm sure
there are many other use cases.
This would be useful for std.typecons.scoped - class instances
can be moved otherwise (which is illegal).
I think if structs can disable
On Wednesday, 15 June 2016 at 20:33:54 UTC, Steven Schveighoffer
wrote:
It could probably do this. Dereferencing a void * isn't valid,
so it kind of has the same effect. However, there are many
functions which take void * and do write to/read from the data
pointing at it (e.g. memcpy). These
On Wednesday, 15 June 2016 at 17:35:49 UTC, Steven Schveighoffer
wrote:
On 6/15/16 6:32 AM, Nick Treleaven wrote:
My question is: would returning void* instead really be
unsafe, i.e. is
there a way of dereferencing it in safe code? (I'm not
thinking about
holes in @safe, but ways by
Hi,
Walter's made a fix for arr[$..$].ptr being unsafe to dereference
- .ptr will be @system:
https://github.com/dlang/dmd/pull/5860
A referenced druntime pull mentioned having a safe wrapper for
.ptr that allows comparison of the pointer value, but does not
allow dereference. The wrapper
On Wednesday, 8 June 2016 at 17:23:22 UTC, deadalnix wrote:
I wonder if Andrei's allocator API supports freeing with a
size argument.
...
This extra bit of infos seems to be less useful in practice
than you'd naively expect. Someone may come up with something
interesting to do with it
On Wednesday, 8 June 2016 at 12:38:25 UTC, Andrei Alexandrescu
wrote:
On 6/8/16 1:59 PM, Nick Treleaven wrote:
I wonder if Andrei's allocator API supports freeing with a
size argument.
Size is required with all deallocations. -- Andrei
Thanks. So I suppose it's up to each allocator whether
On Wednesday, 8 June 2016 at 03:50:26 UTC, deadalnix wrote:
(a fast malloc already needs to be able to find the allocation
metadata from free's argument effisciently,
BTW GLib (GTK+) have a GSlice API that doesn't allow resizing and
requires the allocation size to be passed when freeing:
On Friday, 27 May 2016 at 21:25:50 UTC, Andrei Alexandrescu wrote:
On 05/27/2016 05:02 PM, Era Scarecrow wrote:
With the current state of things, I'll just take your word
on it.
Reasoning is simple - yes we could safely convert to
const(char)[] but that means effectively all refcounting is
On Monday, 30 May 2016 at 14:18:38 UTC, Nick Treleaven wrote:
On Monday, 30 May 2016 at 10:55:57 UTC, Marc Schütz wrote:
auto tmp = stdin.byLine;
auto lines = tmp.array;
Here, `lines` contains references to the buffer owned by
`tmp`, but doesn't escape (assuming `array` takes its
On Monday, 30 May 2016 at 10:55:57 UTC, Marc Schütz wrote:
On Sunday, 29 May 2016 at 14:27:51 UTC, Nick Treleaven wrote:
What about if the RCArray (of ref count 1) is assigned to a
different one after the local ref is initialised? That is what
we're discussing -it's your example above(!)
On Friday, 27 May 2016 at 11:50:42 UTC, Marc Schütz wrote:
On Friday, 27 May 2016 at 10:04:14 UTC, Nick Treleaven wrote:
On Thursday, 26 May 2016 at 08:29:41 UTC, Marc Schütz wrote:
RCArray!int arr = [7];
ref r = arr[0];
arr = [9];// this releases the old array
r++; //
On Thursday, 26 May 2016 at 08:29:41 UTC, Marc Schütz wrote:
On Wednesday, 25 May 2016 at 19:47:06 UTC, Nick Treleaven wrote:
On 24/05/2016 14:48, Nick Treleaven wrote:
@safe unittest
{
RCArray!int arr;
+ arr.length = 1;
ref r = arr[0];
arr.destroy; // refcount drops to
On 24/05/2016 14:48, Nick Treleaven wrote:
On Monday, 23 May 2016 at 17:03:32 UTC, Marc Schütz wrote:
On Monday, 23 May 2016 at 15:18:51 UTC, Nick Treleaven wrote:
I think the reason D doesn't support local refs is because it would
make it harder to design @safe, particularly with the planned
On Monday, 23 May 2016 at 17:43:49 UTC, deed wrote:
On Monday, 23 May 2016 at 15:18:51 UTC, Nick Treleaven wrote:
Recomputation or not, @safe or @system, should be no different
from the expanded code. So within a scope, after aliasing 'm',
'm' should be replaced by 'matrix.rawArr'. Everything
On Monday, 23 May 2016 at 17:03:32 UTC, Marc Schütz wrote:
On Monday, 23 May 2016 at 15:18:51 UTC, Nick Treleaven wrote:
If we had local refs, we could use this instead:
ref m = matrix.rawArr;
Note that this wouldn't work with rvalues, which `with`
supports.
OK. I suppose supporting
On Monday, 23 May 2016 at 14:05:43 UTC, deed wrote:
Some thoughts about extending the with-statement were brought
up here earlier:
http://forum.dlang.org/post/txpifmwpmmhsvcpbc...@forum.dlang.org
I don't care much whether it would be with, alias or possibly
something clever already existing,
On Thursday, 12 May 2016 at 02:51:33 UTC, Lionello Lunesu wrote:
I'm trying to think of a case where changing a single value
into a tuple with 2 (or more) values would silently change the
behavior, but I can't think of any. Seems to me it would always
cause an error, iff the result of the
On Friday, 13 May 2016 at 00:47:04 UTC, Jack Stouffer wrote:
If you're serious about removing auto-decoding, which I think
you and others have shown has merits, you have to the THE
SIMPLEST migration path ever, or you will kill D. I'm talking a
simple press of a button.
char[] is always
On Wednesday, 11 May 2016 at 13:29:56 UTC, Gopan wrote:
int x;
while( scanf("%d", ), x!= 0) // until user input 0.
{
//do something with x
}
Without the comma operator, I would have to repeat the scanf
statement.
int x;
scanf("%d", );
while(x != 0)
{
//do something with x
On 10/05/2016 12:12, Tomer Filiba wrote:
Alternatively, an isVersion(x) predicate that I could use in a static if
could do the trick -- although I think ``version(x || y)`` is more
readable than ``static if (isVersion(x) || isVersion(y))``
This is actually longer for 2 arguments, but can scale
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
On Thursday, 28 April 2016 at 22:37:41 UTC, H. S. Teoh wrote:
I find for(;;) far more logical than other vacuous workarounds
like
while(1) or while(true).
It's only because of C that all the for arguments can be left
out, I'd rather have:
while {...}
I.e. it defaults to true. 'A while' is
On Friday, 29 April 2016 at 06:27:07 UTC, Jacob Carlborg wrote:
In an ideal world the language would support trailing delegate
syntax allowing this to work without any language support:
forever {
}
Translated to:
forever({
});
Or maybe with macros supporting a trailing statement as the
On Thursday, 28 April 2016 at 19:45:47 UTC, Steven Schveighoffer
wrote:
If you don't want to mutate it, don't put var in the parameter
name. I put var there because I wanted to mutate it. Swift
requires that already. It just now won't let you do it in the
parameter declaration, you have to
On Thursday, 28 April 2016 at 18:49:54 UTC, Steven Schveighoffer
wrote:
1. Swift 3 will no longer allow mutable variables as
parameters. Instead, your parameters will be immutable, or
reference (inout). To fix this, you can assign your immutable
variable to a mutable one (immutability is
On 25/04/2016 11:16, Nick Treleaven wrote:
On Friday, 22 April 2016 at 19:09:40 UTC, David Nadlinger wrote:
alias Instantiate(alias Template, Params...) = Template!Params;
Ah, maybe I'd even seen this in passing and forgot. Good point about
aliasSeq template elements, let's make this public.
On Friday, 22 April 2016 at 19:09:40 UTC, David Nadlinger wrote:
From std.meta:
---
/*
* Instantiates the given template with the given list of
parameters.
*
* Used to work around syntactic limitations of D with regard
to instantiating
* a template from an alias sequence (e.g. T[0]!(...)
On Saturday, 23 April 2016 at 20:50:31 UTC, Adam D. Ruppe wrote:
I still can't get over the ridiculous grey constraints. WTF.
It's much better reading signatures than before.
But what we could do is add a margin-bottom to them if needed,
while keeping the others hugged up.
Good idea,
On Friday, 15 April 2016 at 18:46:01 UTC, Steven Schveighoffer
wrote:
inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2)
Might be nice if inout applied to template parameter types:
T[] overlap(inout T)(T[] r1, T[] r2);
If it wasn't for the virtual function issue, I wonder if inout
would
201 - 300 of 459 matches
Mail list logo
