On Wednesday, 10 August 2022 at 06:15:39 UTC, Dom Disc wrote:
Ok, then I consider this is a bug in Phobos that should be
corrected.
All instances of
```D
foo(T : fixedType)(T x) { }
```
should be replaced by
```D
foo(fixedType x) { }
```
Perhaps, but not necessarily. The body of foo could
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()
{
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:
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
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
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
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
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
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
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,
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
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[$] =
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
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?
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.
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 {
On Friday, 5 July 2019 at 23:05:32 UTC, Jonathan M Davis wrote:
Yes, I was wondering why the compiler doesn't statically
allocate it automatically as an optimization.
It would have to be set up to store the literal somewhere else.
I was thinking the read-only data segment.
Certainly, it
On Thursday, 4 July 2019 at 11:06:36 UTC, Eugene Wissner wrote:
static immutable arr = [1, 2];
You have to spell it out that the data is static.
Yes, I was wondering why the compiler doesn't statically allocate
it automatically as an optimization.
immutable(int[]) f() @nogc {
return [1,2];
}
onlineapp.d(2): Error: array literal in `@nogc` function
`onlineapp.f` may cause a GC allocation
This makes dynamic array literals unusable with @nogc, and adds
to GC pressure for no reason. What code would break if dmd used
only static data
Ok, thanks for explaining. Nice idea.
On Tuesday, 28 May 2019 at 09:25:51 UTC, dangbinghoo wrote:
class NSconf
{
String name;
...
}
Does this class have a non-default constructor?
On Tuesday, 28 May 2019 at 09:25:51 UTC, dangbinghoo wrote:
writeln(Object.factory("gwlib.entity.nsconf.NSConf"));
Typo, should be NSconf.
Hi,
Last week's TWiD had a tip that didn't make sense:
http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_20.html#tip-of-the-week
template Locals(int i) {
alias Whatever = int;
}
static foreach(i; [1, 2, 3]) {
Locals!i.Whatever;
}
The body is just `int;`. Not sure how to reach Adam.
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
On Thursday, 11 October 2018 at 23:17:15 UTC, Jonathan Marler
wrote:
For example, the "Conditional operator" in D actually has a
higher priority than an assignment, but in C++ it's the same
and is evaluated right-to-left. So this expression would be
different in C++ and D:
a ? b : c = d
In
On Thursday, 4 October 2018 at 06:43:02 UTC, Gopan wrote:
I have seen people enclosing the function logic inside a
while(1) merely to stick on to single return at the end.
while(1)
{
...
break; //otherwise return would come here.
...
break;
}
return ...;
I
Rust's lifetime syntax is noisy - the scope name is repeated, and
why require a name if it's usually not given a meaningful one
(`a`)?
Rust is more limited semantically due to unique mutability, so it
may have different requirements for function signatures to D. (I
think they recently
On Thursday, 23 August 2018 at 09:09:40 UTC, Shachar Shemesh
wrote:
Please see the thread about lazy [1] for a case where a
question actually has an answer, but nobody seems to know it
I updated the spec for lazy parameters to add a link to lazy
variadic functions at the end, and for the
On Tuesday, 21 August 2018 at 13:42:31 UTC, Kagamin wrote:
int[] escape(scope int[] r)
{
return r; //error, can't return scoped argument
}
...
int[] escape(T)(scope int[] r)
{
return r; //ok! `scope` silently promoted to `return`
}
You can't have strictly scoped parameter in a
On Wednesday, 15 August 2018 at 16:56:39 UTC, Everlast wrote:
foo(int x = 3);
foo(auto x = 3);
If one has to declare the type it reduces it's effectiveness.
auto is not a type ;-) Having e.g. auto or a type makes it clear
that a new variable is being defined. I'd like this to work
inside a
On Tuesday, 31 July 2018 at 20:03:39 UTC, ag0aep6g wrote:
Looks like you can do it with a "lazy variadic function" [1],
Interesting, thanks. I've made a pull to add a See Also link
about this to the Lazy Parameters docs:
https://github.com/dlang/dlang.org/pull/2439
On Friday, 3 August 2018 at 21:27:50 UTC, dlangPupil2 wrote:
In lieu of a whole new edition maybe a web page listing major
changes to D since Andrei's book came out might be useful (and
help sales of his existing book too!!)
https://wiki.dlang.org/Differences_With_TDPL
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
On Tuesday, 10 July 2018 at 10:47:04 UTC, RazvanN wrote:
[1] https://github.com/dlang/DIPs/pull/129
Thanks for making the DIP. I can't get this code to compile (my
struct has an `int i` field):
static foreach (i, ref field; src.tupleof)
this.tupleof[i] = field;
Error: constant value
On Wednesday, 4 July 2018 at 14:37:49 UTC, Timon Gehr wrote:
if (a+b)*c == d { ... }
Error: found `{` when expecting `;` following statement
Adding the semi-colon, `*c == d;` would likely cause:
Error: `*c == d` has no effect
Also multiplying (a+b) by a pointer is illegal, and c is probably
On Wednesday, 27 June 2018 at 16:00:37 UTC, Mario Silva wrote:
Less than an year ago our project was taking around 17 seconds
to compile - no libs requiring compilation - and maybe around
50 seconds for full compilation, and it now takes around 50
seconds for an incremental compilations and
On Sunday, 24 June 2018 at 23:40:56 UTC, Timoses wrote:
The others may be rewritten to not have a leading "!" as well,
e.g.
if (!(t1.ty == Tarray && t2.ty == Tarray && needsDirectEq(t1,
t2))
if (t1.ty != Tarray || t2.ty != Tarray || ...)
Yes, but you might make a mistake, and sometimes it
On Friday, 25 May 2018 at 08:27:30 UTC, Dukc wrote:
If you add two characters, it interprets it as a concatenation
that results in a string with two charactes.
...
Now, if I were programming in D, this would not have happened.
Using + always means an addition.
I don't think it makes sense to
On Tuesday, 15 May 2018 at 15:02:36 UTC, jmh530 wrote:
auto opDispatch(string s)()
if (s == "bar")
In case anyone isn't aware, this is better written:
auto opDispatch(string s : "bar")()
On Monday, 8 June 2015 at 21:32:52 UTC, Timon Gehr wrote:
On 06/08/2015 10:16 PM, Idan Arye wrote:
It would be nice together with this feature to be able to mixin
identifiers:
static foreach (ident; ["foo", "bar"])
{
auto mixin(ident)()
{
// code for
On Monday, 14 May 2018 at 01:20:38 UTC, Jonathan M Davis wrote:
Yeah. It's been discussed that it should be illegal to declare
a struct or class member named init, but that change has yet to
happen.
https://issues.dlang.org/show_bug.cgi?id=7066
Walter and Timon have considered redefinition
On Wednesday, 18 April 2018 at 13:36:15 UTC, FeepingCreature
wrote:
That said, I'm pretty sure that get will throw anyways if
invoked without a default value.
Not in release mode, but I suppose that doesn't matter. I've made
a pull to update the docs to reflect this:
On Wednesday, 18 April 2018 at 16:04:13 UTC, Giles Bathgate wrote:
I understand where you are coming from, but I am not sure it is
appropriate to shoehorn every use case into one api.
It is not shoehorning, the difference here is just returning by
ref vs pointer. I understand that, as the
On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:
You can get a pointer from the ref return:
Value* p = ("key", { inserted = true; return
Value.init; });
This is not @safe, even with -dip1000:
Error: cannot take address of ref return of f() in @safe function
main
On Wednesday, 18 April 2018 at 08:24:14 UTC, FeepingCreature
wrote:
If nobody objects, I'll make a PR to deprecate it.
+1. Nullable has received some improvements lately, it would be
great if `get` was no longer implicit. For new code, it is
trivial to write `.get` to convert to the original
On Tuesday, 17 April 2018 at 20:49:30 UTC, Steven Schveighoffer
wrote:
Why do you think it's less efficient to use a lazy parameter?
Wouldn't an extra function call have to happen, at least in some
cases?
This pattern needs a pointer to be returned, instead of using
`ref`. Note that `` is
On Sunday, 15 April 2018 at 22:52:47 UTC, Giles Bathgate wrote:
The function provides a means to get a value corresponding to
the key, but if the value doesn't exist it will evaluate the
lazy argument to create a new value, add this to the
associative array and then return it.
auto p =
On Thursday, 12 April 2018 at 00:32:49 UTC, Uknown wrote:
Adding a destructor makes the compiler return an error about
lifetimes, with or without -dip1000
Thanks. Filed, mentioning this:
https://issues.dlang.org/show_bug.cgi?id=18756
Is this a known bug? With v2.079.0, with or without -dip1000:
@safe unittest
{
struct S
{
int i;
}
auto p = ().i;
}
The address of field `i` should not escape, right? It's also
incorrectly allowed when using an lvalue of S (when -dip1000 is
not present).
On Thursday, 5 April 2018 at 18:46:25 UTC, H. S. Teoh wrote:
I like this idea. Except the syntax could be improved:
this(this orig) // <-- N.B.
{
It's already valid syntax, equivalent to `this(typeof(this)
orig)`. It can be called explicitly, but is ignored for
On Saturday, 24 March 2018 at 17:34:09 UTC, Manu wrote:
You mutate a temporary that times out at the end of the
statement...
your statement is never assigned to anything, and has no effect.
That is solved by having the ref function return its argument (so
it can be chained):
struct S;
ref
On Sunday, 18 March 2018 at 18:45:23 UTC, Steven Schveighoffer
wrote:
unittest
{
auto foo = new Foo;
assert(foo.internalbuffer.empty); // note, this is a private
symbol.
}
I don't understand why you would want a private symbol in a
*documented* unittest, the reader of the
On Wednesday, 28 March 2018 at 06:43:15 UTC, Shachar Shemesh
wrote:
For those too lazy to click on the link,
BTW It's not the reader's 'laziness', it's basic courtesy on the
part of the poster to the newsgroup to provide a meaningful
subject line for a thread. Far more people will read the
On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer
wrote:
If you limit to class members, then you have to do something
like C++ friends, which are unnecessarily verbose.
Not if you also have a module-level visibility modifier, which
could have been `module`.
IMO, the
On Tuesday, 13 March 2018 at 05:11:48 UTC, psychoticRabbit wrote:
If you have access to the module source, you have access to
the source of types inside it. Making the module the lowest
level of encapsulation makes sense from that perspective.
There are two problems I see:
1st - D has broken
On Wednesday, 17 January 2018 at 06:44:21 UTC, Timon Gehr wrote:
It uses tuples because it uses zip. The code does not compile
today, because the lambda I'm passing to "map" has two
parameters:
auto a = [1, 2, 4, 7, 2];
auto b = [3, 5, 3, 2, 4];
// auto c = zip(a, b).map!((x, y) => x + y);
On Monday, 12 March 2018 at 16:51:06 UTC, H. S. Teoh wrote:
For example, today you can already make opBinary() return
something other than the parent type, and use alias this to
make it decay to the parent type.
Sounds like this:
https://en.wikipedia.org/wiki/Expression_templates
On Wednesday, 28 February 2018 at 20:01:34 UTC, H. S. Teoh wrote:
As Andrei wrote in TDPL, (and I paraphrase,) it sucks when
built-in types have magical abilities inaccessible to user
code. This is a common defect in many programming languages...
the "magical" behaviour is wonderful when it
On Wednesday, 7 March 2018 at 13:24:25 UTC, Jonathan M Davis
wrote:
I'd actually argue that that's the lesser of the problems with
auto-decoding. The big problem is that it's auto-decoding. Code
points are almost always the wrong level to be operating at.
For me the fundamental problem is
On Monday, 26 February 2018 at 21:07:52 UTC, Meta wrote:
This is possible in the language today using the implicit class
construction feature of runtime variadic arrays:
class VArray
{
Variant[] va;
this(T...)(T ts) { foreach(t; ts) { va ~= Variant(t); } }
}
void test(VArray ta...)
On Monday, 26 February 2018 at 21:36:49 UTC, ketmar wrote:
aliak wrote:
It makes libraries *much* more intuitive and expressive (C++
just got it wrong by choosing the wrong default). If you allow
library authors to opt in instead of opt out then it becomes a
conscious decision for one.
On Sunday, 11 February 2018 at 15:34:07 UTC, Andrei Alexandrescu
wrote:
I'm trying to sketch a simple compile-time reflection system,
and https://issues.dlang.org/show_bug.cgi?id=18422 is a blocker
of the entire approach.
BTW please write a descriptive subject, not a bug ID. The
#dbugfix
On Wednesday, 31 January 2018 at 12:35:37 UTC, Nick Treleaven
wrote:
It's now called an Expression List:
https://dlang.org/ctarguments.html#homogenous-lists
That page needs an update too, we should call them sequences.
I'll try to update the docs soon.
There are still various places that
On Sunday, 28 January 2018 at 06:44:28 UTC, Timothee Cour wrote:
likewise the following compiles, but IMO should not:
class A{ void fun(this a){}}
(instead we should have typeof(this)
Yes, it's also confusing reading it, I thought it was template
this for a second. It even works if fun is
On Friday, 26 January 2018 at 19:44:21 UTC, Dechcaudron wrote:
See, for instance, definition
https://dlang.org/spec/class.html#class_properties. If it is
defined anywhere, I cannot seem to find it.
It's now called an Expression List:
https://dlang.org/ctarguments.html#homogenous-lists
I'll
On Wednesday, 24 January 2018 at 14:22:59 UTC, Meta wrote:
One way we could probably improve the error message is to
change it to "template struct test.A(int var = 3) is used as a
type. It must be instantiated", or something along those lines,
to make it clear why you can't use A as a type.
On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote:
Unqual is the standard way today to get a head-mutable version
of something. For dynamic arrays, static arrays, pointers and
value types, including structs without aliasing, thi works. For
AAs, classes, and structs with aliasing,
On Tuesday, 19 December 2017 at 08:54:38 UTC, Petar Kirov
[ZombineDev] wrote:
Reminds me of C#7's out variable declarations:
https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-7#out-variables
However multiple return values are much better implemented
through language-integrated
On Tuesday, 19 December 2017 at 11:30:14 UTC, ketmar wrote:
but Rikki, we have this! i'm using refcounted structs for
years, and it works like a charm! ;-)
You can either have guaranteed memory-safe (due to DIP1000) but
inefficient RC (due to extra runtime checks*), or efficient and
not
On Wednesday, 6 December 2017 at 17:11:49 UTC, Nick Treleaven
wrote:
0x005482C2 in nothrow void*
ddmd.root.filename.extendedPathThen!(ddmd.root.file.File.read().__lambda1).extendedPathThen(const(char*)) at C:\git\dmd\src\ddmd\root\filename.d(834)
0x005480E8 in File at
On Wednesday, 6 December 2017 at 17:04:06 UTC, A Guy With a
Question wrote:
abstract class Test(T)
Here you have a class template.
It does produce there error when I do this:
class Test2
: Test!int
You instantiated the template, so the compiler can now type check
the instantiated
Hi,
I checked out dmd and druntime this morning. dmd seems to build
fine, but when I try druntime I get this error:
$ make -f win32.mak
..\dmd\generated\windows\release\32\dmd -conf= -c -o- -Isrc
-Iimport -Hfimport\core\sync\barrier.di src\core\sync\barrier.d
DMD v2.077.1
DEBUG
On Thursday, 30 November 2017 at 16:31:25 UTC, Nordlöw wrote:
How would this interact with explicit scope-qualification of
`x`?
That would allow the compiler to avoid GC allocation for x. It
seems essentially the same case as Walter describes here:
On Wednesday, 29 November 2017 at 17:50:59 UTC, Arun
Chandrasekaran wrote:
Multiple alias this
You can only have one subtyping member currently.
Shared
Not all of shared's guarantees are implemented yet.
SafeD
@safe (and therefore SafeD) isn't fully implemented. So, it
doesn't necessarily
On Sunday, 19 November 2017 at 22:54:38 UTC, Walter Bright wrote:
I can't see the problem. You go from nullable to non-nullable
by checking for null, and the other direction happens
implicitly.
Implicit conversions have their problems with overloading,
The C# implementation doesn't affect
On Wednesday, 4 October 2017 at 20:49:26 UTC, John Gabriele wrote:
What's changed in the language, library, and community since
then that I should be aware of if following along with and
learning from that book?
Here's a list of significant things - maybe incomplete:
On Thursday, 23 November 2017 at 06:35:17 UTC, codephantom wrote:
I love not being able to edit posts. It's so convenient.
It's not as much of a problem as not being able to hide all posts
by a user who repeats arguments, derails the conversation onto
irrelevant side discussions and judges
On Sunday, 19 November 2017 at 11:54:04 UTC, Tony wrote:
dmd --version
DMD64 D Compiler v2.077.0
Copyright (c) 1999-2017 by Digital Mars written by Walter Bright
dmd test_contracts.d
test_contracts.d(13): Error: missing `body { ... }` after `in`
or `out`
Just made a pull to fix this:
On Sunday, 19 November 2017 at 22:54:38 UTC, Walter Bright wrote:
There's also an issue of how to derive a class from a base
class.
If you want null, use a nullable type:
Base b = ...;
Derived? d = cast(Derived?) base;
if (d !is null) d.method;
This implies one must know all the use cases of
On Monday, 20 November 2017 at 17:13:37 UTC, Oleg B wrote:
Hello. I know about some implementation issues
http://forum.dlang.org/thread/nqctbzhrdldmnffch...@forum.dlang.org
What work must be done for fix it? For what time is it
scheduled?
Looks like Walter is working on it:
On Tuesday, 14 November 2017 at 13:43:32 UTC, Michael V. Franklin
wrote:
Nick, if it's not in bugzilla already, can you please add it?
Sure:
https://issues.dlang.org/show_bug.cgi?id=17983
On Sunday, 12 November 2017 at 16:57:05 UTC, Andrei Alexandrescu
wrote:
The overload being called depends on (a) whether a - b can be
computed during compilation or not, and (b) the actual value of
a - b. Clearly a big problem for modular code. This is the
smoking gun motivating the DIP.
An
On Tuesday, 7 November 2017 at 13:43:20 UTC, user1234 wrote:
On Monday, 6 November 2017 at 20:14:17 UTC, Meta wrote:
The functionality is probably a good idea, but a library
solution is doable today without any acrobatics.
Show me a library solution that works fine with IDE completion
(so
On Saturday, 11 November 2017 at 05:20:39 UTC, codephantom wrote:
I just saw this about the new 'damnit' operator, for C# 8.
https://github.com/dotnet/csharplang/issues/556
The principle is a good one - by default you cannot dereference
something that can be null, you get a compiler error
On Monday, 6 November 2017 at 13:02:43 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 6 November 2017 at 10:12:11 UTC, Jonathan M Davis
wrote:
All it does is take the expression
x ? x : y
and make it
x ?: y
Yes, that is an issue because it means that typos no longer are
caught. E.g. if you
On Thursday, 2 November 2017 at 20:37:11 UTC, user1234 wrote:
switch (i)
default: break;
}
you have 3 non-ambiguous and contiguous statements without a
block: a switch, a default case (the "free-floating" one) and a
break. Now why is this allowed is another story ;)
I've found a
On Saturday, 4 November 2017 at 06:08:22 UTC, Jonathan M Davis
wrote:
Heck, take a really simply one like sqrt. All you have to check
in the out contract is the return value. You have no idea what
was passed in. So, how would you write an out contract
verifying that you got the correct number?
On Friday, 3 November 2017 at 02:32:41 UTC, Jonathan M Davis
wrote:
Personally, I hate how verbose they are, but my solution is
just not to use them. And IMHO, the only place that they add
real value is in classes, where their success or failure can be
& or ||ed based on how that should work
On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu
wrote:
Walter and I decided to kick-off project Elvis for adding the
homonym operator to D.
I'd like to mention null-coalescing assignment syntax. Perl has
`$a //= $b`, and PHP has voted to support `$a ??= $b`, expanding
to
On Sunday, 27 August 2017 at 10:28:29 UTC, Dukc wrote:
The problem with geany is that it's syntax highlighting and
auto-completion depend on having the file where the symbol's
defined open.
No, Geany supports generation and automatic loading of global
tags files:
On Friday, 28 July 2017 at 16:58:41 UTC, Moritz Maxeiner wrote:
Having a keyword delimit the end of an optional is both
redundant and inconsistent
You are arguing against the current syntax, not my proposal. In
my case the `do` keyword would be disambiguating between out
expressions and out
On Friday, 28 July 2017 at 16:44:24 UTC, MysticZach wrote:
On Friday, 28 July 2017 at 11:04:23 UTC, Nick Treleaven wrote:
One option to solve the out contract ambiguity and aid parsing
by tools is to require 'do' after out contract expressions.
BTW `do` would only be required before the {}
On Friday, 28 July 2017 at 01:50:24 UTC, Jonathan M Davis wrote:
Should public have @ on it? Should static have @ on it? What
about scope, const, or shared?
If they are storage classes, they shouldn't have @. If they are
statement or expression keywords, they shouldn't have @. Things
like
On Friday, 21 July 2017 at 13:51:05 UTC, Mike Parker wrote:
DIP 1009 is titled "Improve Contract Usability".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1009.md
I think the proposed in/out expression contracts should require
pure expressions. In the rare case that impurity is required,
On Saturday, 22 July 2017 at 10:17:49 UTC, Temtaime wrote:
The new precise GC will be never added to druntime.
2.075 has precise scanning of the DATA and the TLS segments (on
Windows):
http://dlang.org/spec/garbage.html#precise_dataseg
This seems like significant progress towards precise
On Monday, 24 July 2017 at 13:12:17 UTC, Nick Treleaven wrote:
static if (is(E == enum; alias V)) { // this inserts "V"
V v;
}
The test comes first as it logically should, as the alias is
not being used until the following statement.
Hmm, it can be used in the test:
is(Abc U : U*)
is(AA
On Monday, 24 July 2017 at 13:12:17 UTC, Nick Treleaven wrote:
On Friday, 21 July 2017 at 21:50:02 UTC, Johan Engelen wrote:
static if (is(E V == enum)) { // this inserts "V"
V v;
}
```
Yes, but this is a bit different as the goal is to avoid
repeating V
Sigh. Repeating E.
On Friday, 21 July 2017 at 21:50:02 UTC, Johan Engelen wrote:
We do have a construct like that already:
```
static if (is(E V == enum)) { // this inserts "V"
V v;
}
```
Yes, but this is a bit different as the goal is to avoid
repeating V (as it may be complex). Repeating a local variable
On Friday, 21 July 2017 at 11:19:47 UTC, Patrick Schluter wrote:
In C there's no point in the X macro anymore since C99.
Designated initializer allow to do it properly[1] now.
enum COLORS { red, blue, green, max };
char *cstring[max] = {[red]="red", [blue]="blue",
[green]="green" };
On Monday, 3 July 2017 at 18:14:43 UTC, Johan Engelen wrote:
The spec (or DMD frontend) is broken regarding struct
initialization with explicit mention of member field names:
https://dlang.org/spec/struct.html#static_struct_init
I agree, PR:
https://github.com/dlang/dlang.org/pull/1794
101 - 200 of 459 matches
Mail list logo
