On Saturday, 5 May 2018 at 15:39:19 UTC, Jonathan M Davis wrote:
On Saturday, May 05, 2018 15:22:04 Bolpat via Digitalmars-d
wrote:
On Friday, 4 May 2018 at 09:34:14 UTC, Jonathan M Davis wrote:
> [...]
> It's actually not infrequent now that in C++, you want to
> pass
> stuf by value rather t
On Sunday, 14 January 2018 at 00:01:15 UTC, rikki cattermole
wrote:
On 13/01/2018 11:45 PM, Timothee Cour wrote:
some people have suggested using `{a, b}` instead of `(a,b)` ;
this
would not work because of ambiguity, eg:
`auto fun(){ return {}; }`
already has a meaning, so the empty tuple woul
On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
[...]
This DIP aims to make code like the following valid D:
---
auto (a, b) = (1, 2);
(int a, int b) = (1, 2);
---
[...]
How is (1, 2) different from [1, 2] (static array)? It makes no
sense to me to have both and probably a bunch
When I wanted something like
static if (enum var = expr)
{ ... }
I did
static foreach (enum var; { auto x = expr; return x ? [ x ] : [
]; }())
{ ... }
The only drawback is, there is no `else`.
You can use the trick even for normal if when the condition is
not identical to the expre
On Thursday, 7 December 2017 at 23:00:38 UTC, Mike Franklin wrote:
If you think D should support something like this, the first
thing to do is to file a bug report.
Sounds more like a DIP to me. There is no way to enable this
without some kind of nontrivial syntax. I'd go with the VB
approach
On Thursday, 7 December 2017 at 15:14:48 UTC, Adam D. Ruppe wrote:
On Thursday, 7 December 2017 at 00:45:21 UTC, Mike Franklin
wrote:
// Error: A.f called with argument types () matches both:
A.f() and A.f()
// Yeah, that error message could be better.
//a.f();
(cast(I)a).f();
Say I have two interfaces
interface I { void f(); }
and
interface J { int f(); }
implemented by some class
class A : I, J {
// challenge by the compiler:
// implement f()!
}
VB.NET allows that by renaming the implementation (it does allow
it generally, not only i
On Monday, 16 October 2017 at 23:29:46 UTC, sarn wrote:
On Sunday, 15 October 2017 at 15:19:21 UTC, Q. Schroll wrote:
On Saturday, 14 October 2017 at 23:20:26 UTC, sarn wrote:
On Saturday, 14 October 2017 at 22:20:46 UTC, Q. Schroll
wrote:
Therefore, and because of brackets, you can distinguish
On Saturday, 14 October 2017 at 23:20:26 UTC, sarn wrote:
On Saturday, 14 October 2017 at 22:20:46 UTC, Q. Schroll wrote:
Therefore, and because of brackets, you can distinguish f(1,
2) from f([1, 2]).
But in f([1, 2]), it's ambiguous (just by parsing) whether [1,
2] is a tuple literal or a d
I've thought about tuples and stuff for a while. For tuples, I'll
use [brackets]. Reasons follow.
Homogeneous tuples are repetitions of some single type. We have
them today in form of static arrays. We could allow
"inhomogeneous arrays" and call them tuples. T[n] is then an
alias for [T, T, .
On Friday, 13 October 2017 at 14:50:44 UTC, Adam D. Ruppe wrote:
[snip]
But actually, I really wish D just had implicit ctors on the
types themselves. I think C++'s mistake was that implicit was
the default, and you have to write `explicit`. If we did the
opposite, where implicit was opt in, I
On Friday, 13 October 2017 at 13:01:48 UTC, Steven Schveighoffer
wrote:
On 10/12/17 7:57 PM, Q. Schroll wrote:
We have some sort of implicit construction already. Weirdly,
it's reserved for classes. Just look at this:
class C { this(int x) { } }
void foo(C c ...) { }
void main()
We have some sort of implicit construction already. Weirdly, it's
reserved for classes. Just look at this:
class C { this(int x) { } }
void foo(C c ...) { }
void main() { foo(0); }
If you put @nogc in front of ctor and functions, the compiler
tells you not to use 'new' in main whil
On Friday, 1 September 2017 at 23:13:50 UTC, Q. Schroll wrote:
[..]
Just as Scott Meyers said: make it easy to use correctly and
hard to use incorrectly. Today it's easy to use incorrectly.
While
enum foo = [1,2,3];
assert(foo is foo);
fails,
enum bla = "123";
assert(foo is foo);
passe
On Friday, 1 September 2017 at 21:08:20 UTC, Ali Çehreli wrote:
[snip]
> assert(!([1,2,3] is [1,2,3]));
>
> Which is exactly what enum expands to and totally expected.
Where is the
> surprise?
This is not a surprise. Array literals are not identical.
In the surprising case foo is a symbol, see
In [1] it says at 5. that
For this reason, and for legacy reasons, an associative array
key is not allowed to define a specialized opCmp, but omit a
specialized opEquals. This restriction may be removed in future
versions of D.
I'm not completely sure what that means. Does "specialized" mean
In std.experimental.typecons.Final the operators ++ and -- are
disabled. I suspect, this was done with simple types as int in
mind, where increment is nothing different from += 1, which is by
definition an assignment. From the distant standpoint, there is
no reason to disable them at all. They
On Monday, 30 January 2017 at 12:08:06 UTC, Olivier FAURE wrote:
On Monday, 30 January 2017 at 06:38:11 UTC, Jonathan M Davis
wrote:
Personally, I think that effectively having an alias for two
attributes in a single attribute is a confusing design
decision anyway and think that it was a mistak
On Sunday, 11 September 2016 at 07:46:09 UTC, Manu wrote:
I'm having a lot of trouble debugging @nogc functions. I have a
number of debug functions that use GC, but I can't call them
from @nogc code... should debug{} allow @nogc calls, the same
as impure calls?
Generally, there is more to con
I'm pretty sure, someone before me has thought about that. Take
pure as an example, but you can replace it by any subset of pure,
nothrow, @safe and @nogc.
Main reason: Assume a struct with simple opApply
struct R
{
// pure -> error: dg possibly impure
int opApply(scope int de
On Monday, 23 May 2016 at 20:27:43 UTC, Steven Schveighoffer
wrote:
On 5/23/16 4:01 PM, Andrei Alexandrescu wrote:
So swap(a, b) swaps the contents of a and b. This could be
easily generalized to multiple arguments such that swap(a1,
a2, ..., an) arranges things such that a1 gets an, a2 gets a1
On Wednesday, 27 April 2016 at 03:59:04 UTC, Seb wrote:
On Wednesday, 27 April 2016 at 02:57:47 UTC, Walter Bright
wrote:
To prepare for a week in Berlin, a few German phrases is all
you'll need to fit in, get around, and have a great time:
1. Ein Bier bitte!
2. Noch ein Bier bitte!
3. Wo ist
On Sunday, 3 April 2016 at 11:17:17 UTC, Mike Parker wrote:
On Sunday, 3 April 2016 at 10:59:47 UTC, Q. Schroll wrote:
Simple as that, suppose
uint[uint] aa;
Any range supports carrying an index. Not so does the Range
returned by byKey and byValue.
foreach (i, k; aa.byKey) { }
and
Simple as that, suppose
uint[uint] aa;
Any range supports carrying an index. Not so does the Range
returned by byKey and byValue.
foreach (i, k; aa.byKey) { }
and
foreach (i, v; aa.byValue) { }
both don't compile.
Reason (I found out by chance):
If the key or value type is a std.ty
On Friday, 1 April 2016 at 08:52:40 UTC, Q. Schroll wrote:
The methods add and remove return bool values that indicate the
state being changed:
• addreturns true iff key has not been already present.
• remove returns true iff key has been already present.
Should have been
The methods
On Friday, 1 April 2016 at 09:55:58 UTC, cym13 wrote:
On Friday, 1 April 2016 at 08:52:40 UTC, Q. Schroll wrote:
[...]
I most of what is said here, assigning true or false makes for
an aweful API compared to add() and remove(). I agree with Adam
Ruppe that if we are to use AA-like syntax we
On Thursday, 31 March 2016 at 19:57:50 UTC, Walter Bright wrote:
aa[x] = true; // add member x
aa[x] = false; // remove member x
x in aa; // compile error
On Friday, 1 April 2016 at 02:36:35 UTC, Jonathan M Davis wrote:
Still, while it's true that aa.remove is how you'd normally do
it, I thin
One upon time, we decided that we can replace opNeg, opCom, etc.
and opAdd, opSubtract, etc. by generic names opUnary and opBinary.
Why don't we have a single iteration operator? Can't we just
provide the "Reverse" information by some bool argument (or
string if you like maybe more functionali
28 matches
Mail list logo
