to fix it while keeping the same
behavior and performance?
Unless C11 has changed the rules about nested initializers,
that should compile. You might try explicit nesting:
```d
stb_easy_font_color c = { {255,255,255,255} };
```
And please file an issue if there isn't one already.
(I don't
On Sunday, 19 December 2021 at 03:27:50 UTC, Tejas wrote:
Oh wow, the executable gets named `stuff` if that's the first
file passed... always thought it would name it the same name as
that file which contained `main`
If the name of the file with `main` were used, you'd have to have
a
to fix it while keeping the same
behavior and performance?
Unless C11 has changed the rules about nested initializers,
that should compile. You might try explicit nesting:
```d
stb_easy_font_color c = { {255,255,255,255} };
```
And please file an issue if there isn't one already.
(I don't
?
Unless C11 has changed the rules about nested initializers, that
should compile. You might try explicit nesting:
```d
stb_easy_font_color c = { {255,255,255,255} };
```
And please file an issue if there isn't one already.
(I don't know what struct __tag21 is. It's not anywhere in the
source
I've been trying to get the stb header library to compile.
There's a single remaining failure:
```
typedef struct
{
unsigned char c[4];
} stb_easy_font_color;
stb_easy_font_color c = { 255,255,255,255 }; // use structure
copying to avoid needing depending on memcpy()
```
LDC returns
```
On Sunday, 25 April 2021 at 13:39:54 UTC, JN wrote:
struct Foo
{
int x, y, z;
}
void main()
{
Foo bar = Foo(1,);
}
This compiles without syntax errors, is this expected?
Yes, the
On Sunday, 25 April 2021 at 13:39:54 UTC, JN wrote:
struct Foo
{
int x, y, z;
}
void main()
{
Foo bar = Foo(1,);
}
This compiles without syntax errors, is this expected?
Yes, D allows trailing commas in argument lists.
struct Foo
{
int x, y, z;
}
void main()
{
Foo bar = Foo(1,);
}
This compiles without syntax errors, is this expected?
On Sunday, 7 June 2020 at 23:09:41 UTC, Jack Applegame wrote:
auto const_ua = Unique!(const NonCopyable)(move(ca)); //
error, why???
}
```
Moving *from* a const would violate const. At least, until such
time that the compiler is finally taught about move() (hopefully,
sometime this
On Sunday, 7 June 2020 at 23:09:41 UTC, Jack Applegame wrote:
const NonCopyable const_a;
auto const_ua = Unique!(const NonCopyable)(move(ca)); //
error, why???
You can't move from a const variable.
On Saturday, 6 June 2020 at 11:58:06 UTC, Basile B. wrote:
maybe it shouldn't but then with another message, for example
Error, cannot `void` initialize a `const` declaration.
since that makes very little sense, at least as a local
variable. (as a member, this can be initialized in a
On Saturday, 6 June 2020 at 12:02:03 UTC, MoonlightSentinel wrote:
On Saturday, 6 June 2020 at 08:55:20 UTC, Jack Applegame wrote:
Should it compile?
No, moveEmplace just sees a const reference and doesn't know
that a is void-initialized.
Actually, it knows. Because moveEmplace assumes
On Saturday, 6 June 2020 at 12:54:38 UTC, Stanislav Blinov wrote:
The moveEmpalce should compile...
But not when the *first* argument is const though, like in the
example. For *that*, one would have to insert an additional cast.
On Saturday, 6 June 2020 at 11:58:06 UTC, Basile B. wrote:
On Saturday, 6 June 2020 at 08:55:20 UTC, Jack Applegame wrote:
Should it compile?
I think, it should.
maybe it shouldn't but then with another message, for example
Error, cannot `void` initialize a `const` declaration.
since
On Saturday, 6 June 2020 at 08:55:20 UTC, Jack Applegame wrote:
Should it compile?
No, moveEmplace just sees a const reference and doesn't know that
a is void-initialized.
On Saturday, 6 June 2020 at 08:55:20 UTC, Jack Applegame wrote:
Should it compile?
```d
import std.algorithm.mutation;
void main() {
const char a = void;
const char b ='b';
moveEmplace(b, a); // mutation.d: Error: cannot modify
const expression target
assert(a == 'b
Should it compile?
```d
import std.algorithm.mutation;
void main() {
const char a = void;
const char b ='b';
moveEmplace(b, a); // mutation.d: Error: cannot modify const
expression target
assert(a == 'b');
}
```
I think, it should.
On Thursday, 16 May 2019 at 21:56:52 UTC, Steven Schveighoffer
wrote:
On 5/16/19 10:21 PM, Max Haughton wrote:
https://run.dlang.io/is/cKFsXh
Should this compile, or is return scope T* down to the user to
not escape (Returning directly does not compile)
Answer to subject
On Thursday, 16 May 2019 at 21:21:51 UTC, Max Haughton wrote:
https://run.dlang.io/is/cKFsXh
Should this compile, or is return scope T* down to the user to
not escape (Returning directly does not compile)
This is a bug, as can be showed by repeating the call to
(*boi).writeln - suddenly
On 5/16/19 10:21 PM, Max Haughton wrote:
https://run.dlang.io/is/cKFsXh
Should this compile, or is return scope T* down to the user to not
escape (Returning directly does not compile)
Answer to subject: no. This is a bug. Please file.
Not sure what the solution is, because dip1000 makes
https://run.dlang.io/is/cKFsXh
Should this compile, or is return scope T* down to the user to
not escape (Returning directly does not compile)
On Tuesday, 3 October 2017 at 23:13:00 UTC, Jonathan M Davis
wrote:
On Tuesday, October 03, 2017 22:42:35 SamwiseFilmore via
Digitalmars-d-learn wrote:
On Tuesday, 3 October 2017 at 22:37:17 UTC, SamwiseFilmore
wrote:
> Am I using the ternary operator correctly here, or is this
> an issue with
On Tuesday, October 03, 2017 22:42:35 SamwiseFilmore via Digitalmars-d-learn
wrote:
> On Tuesday, 3 October 2017 at 22:37:17 UTC, SamwiseFilmore wrote:
> > Am I using the ternary operator correctly here, or is this an
> > issue with dmd? I'm using dmd v2.076.0.
>
> I wrapped the ternary in
On Tue, Oct 03, 2017 at 10:37:17PM +, SamwiseFilmore via
Digitalmars-d-learn wrote:
[...]
> string toString() {
> return
> this.value.toString() ~
> " of " ~
> this.suit.toString() ~
> this.suit == CardSuit.diamonds ? "" : "\t" ~
>
On Tuesday, 3 October 2017 at 22:37:17 UTC, SamwiseFilmore wrote:
Am I using the ternary operator correctly here, or is this an
issue with dmd? I'm using dmd v2.076.0.
I wrapped the ternary in parentheses, and it compiled. Still, I'm
wondering about this behavior.
I've created toString() for a struct (which is a lot more
complicated than what I've provided here) that returns a large
number of concatenated strings. Here is the example:
struct Card {
// Flesh out these enums appropriately
CardSuit suit;
CardValue value;
Facing facing;
On Tuesday, 25 August 2015 at 18:29:08 UTC, Vladimir Panteleev
wrote:
I think this is a bug, but is easily worked around with:
auto test(string a) {
return .test(a, b);
}
Thanks, this worked.
Filled it: https://issues.dlang.org/show_bug.cgi?id=14965
On 08/25/2015 08:29 PM, Vladimir Panteleev wrote:
I think this is a bug, but is easily worked around with:
auto test(string a) {
return .test(a, b);
}
I suspect that the reason the error occurs, is that the auto return type
automatically rewrites the function declaration into an
On 08/26/2015 09:55 PM, Timon Gehr wrote:
On 08/25/2015 08:29 PM, Vladimir Panteleev wrote:
I think this is a bug, but is easily worked around with:
auto test(string a) {
return .test(a, b);
}
I suspect that the reason the error occurs, is that the auto return type
automatically
On Wednesday, 26 August 2015 at 20:02:35 UTC, Timon Gehr wrote:
Another workaround is to order the declarations in the opposite
way:
import std.stdio;
import std.range : chain;
auto test(string a,string b) {
return chain(a,b);
}
auto test(string a) {
return test(a,b);
}
void main() {
import std.stdio;
import std.range : chain;
auto test(string a) {
return test(a, b);
}
auto test(string a, string b) {
return chain(a, b);
}
void main() {
writeln(test(a));
}
Ends with: Error: forward reference to inferred return type of
function call 'test'
I know this exact
On Tuesday, 25 August 2015 at 18:19:40 UTC, tchaloupka wrote:
import std.stdio;
import std.range : chain;
auto test(string a) {
return test(a, b);
}
auto test(string a, string b) {
return chain(a, b);
}
void main() {
writeln(test(a));
}
Ends with: Error: forward reference to
32 matches
Mail list logo
