On Saturday, 3 February 2024 at 02:20:13 UTC, Paul Backus wrote:
On Friday, 2 February 2024 at 23:25:37 UTC, Chris Katko wrote:
The auto solution won't work for a struct however which I'm
using:
```D
struct procTable{ //contains all the fields inside a file I'm
parsing
uint time;
int
On Friday, 2 February 2024 at 23:25:37 UTC, Chris Katko wrote:
The auto solution won't work for a struct however which I'm
using:
```D
struct procTable{ //contains all the fields inside a file I'm
parsing
uint time;
int priority;
string name;
// etc
}
```
Maybe you can use
On Friday, 2 February 2024 at 21:01:53 UTC, Paul Backus wrote:
No, D only does bottom-up type inference, not top down.
If you want to avoid repeating the type, use `auto` on the left
side:
```d
auto time = to!uint(data[1]);
auto priority = to!int(data[2]);
```
Okay thanks. It finally
On Friday, 2 February 2024 at 07:43:09 UTC, Chris Katko wrote:
Is there some way to do:
```D
string[3] data; //strings from some file input, some are ints,
uints, etc.
auto into!(T)(T value){return to!???(value); } // ???
uint time = into!(data[1]); // We already know this is uint
int
Is there some way to do:
```D
string[3] data; //strings from some file input, some are ints,
uints, etc.
auto into!(T)(T value){return to!???(value); } // ???
uint time = into!(data[1]); // We already know this is uint
int priority = into!(data[2]);
```
instead of:
```D
uint time = to!uint
On 3/12/23 06:07, DLearner wrote:
> 1. As a shorthand to make the type of the variable being declared the
> same as the type on the right hand side of an initial assignment.
As Adam explained, D already has type inference without a special keyword.
However, some places where 'auto' (or
On Sunday, 12 March 2023 at 13:27:05 UTC, Adam D Ruppe wrote:
[...] *any* storage class will work for type inference. [...]
After heaving read [1] I immediately thought of this:
void main ()
{
deprecated i = 3;
i = 4;
}
$ dmd test.d
test.d(4): Deprecation: variable
On Sunday, 12 March 2023 at 15:31:07 UTC, Salih Dincer wrote:
Moreover, `auto ref` or `ref auto` is needed in functions.
That's because `ref` isn't part of the argument or return value's
type, so it isn't covered by **type** inference. Instead, D has a
totally separate feature for "
.
The auto keyword is really helpful for shortening it. But in at
least 2 cases (one of which is interfaces) it should help the
compiler. For example, contrary to expected, it is dynamic array:
```d
auto arr = [ 1, 2, 3 ];
```
Moreover, `auto ref` or `ref auto` is needed in functions.
SDB@79
On Sunday, 12 March 2023 at 13:07:58 UTC, DLearner wrote:
Is it correct that this _single_ keyword is used to indicate
_two_ quite different things:
No, it only actually does #2 in your thing. The type is optional
meaning *any* storage class will work for type inference. `auto
Is it correct that this _single_ keyword is used to indicate
_two_ quite different things:
1. As a shorthand to make the type of the variable being declared
the same as the type on the right hand side of an initial
assignment.
Example: ```auto A = 5;``` makes A an int.
2. To indicate
Looks like explicitly initialized variable in this case allocates
array literal. Uninitialized variable is initialized with init
pattern. This may be correct as uninitialized variable isn't
guaranteed to hold a value most useful for you, it's only
guaranteed to hold a defined value.
On Wednesday, 26 October 2022 at 04:40:17 UTC, Salih Dincer wrote:
On Tuesday, 25 October 2022 at 13:51:30 UTC, Andrey Zherikov
wrote:
Does the second piece of code shows a bug or my expectation is
not correct (and why if so)?
As a result, if this is a bug, Andrey has the right to report
it.
On Wednesday, 26 October 2022 at 02:34:24 UTC, Ali Çehreli wrote:
On 10/25/22 19:25, Salih Dincer wrote:
> with static in main():
If 'static' makes a difference on your side as well, it is your
turn to create a bug report. :) (Last time you discovered a
bug, I was too quick to report it. :/)
On 10/25/22 19:25, Salih Dincer wrote:
> with static in main():
If 'static' makes a difference on your side as well, it is your turn to
create a bug report. :) (Last time you discovered a bug, I was too quick
to report it. :/)
Ali
too, to use a static struct. I also tried the
following example because it can work with static in main():
import std;
void main() {
//static
struct X
{
static struct Y {
//...
}}
static
struct Bar {
string s;
string toString() {
return s;
}
}
auto l
typeof(screen.output.findSplit("")) s;
Perfect. That was the "essence" of my question. But thanks to
Ali, I don't have to use such esoteric syntax. D is a wonderful
language, but I seem to shoot myself in the foot :)
On 10/25/22 6:07 PM, WhatMeWorry wrote:
I'm naturally getting a undefined identifier `s` error in the return.
Is there some way to refactor my code? I tried to declare s outside of
the else brackets like:
auto screen = executeShell(cmdLine);
auto s;
...
{
s = screen.output.findSplit
On 10/25/22 17:16, Salih Dincer wrote:
> Excuse me, but they still write in purple prose about dynamic
> array literature here!
I've heard positive things about D's arrays from people who use D in
production. Especially slices...
> I've known D for more than 10 years, but the topic we're
On Wed, Oct 26, 2022 at 12:16:55AM +, Salih Dincer via Digitalmars-d-learn
wrote:
[...]
> I've known D for more than 10 years, but the topic we're talking about
> still seems strange to me. The explanations given are not enough for
> me, I'm sorry.
>
> Can anyone tell me what happens when I
On Tuesday, 25 October 2022 at 20:36:28 UTC, matheus wrote:
On
int[] a = [1];
int[] b = a.dup;
assert([0] !is [0]); // different memory
```
This is interesting, I understand the point of "reference vs
copy", and I'm OK with this design choice of, but I wonder in
the case of newcomers if
On 10/25/22 15:07, WhatMeWorry wrote:
> auto screen = executeShell(cmdLine);
> auto s;
That can't work because there is no information to infer the type of
's'. Judging from the return type of getPath, perhaps it's string[]:
string[] s;
This is the question we should answer first
On 10/25/22 13:36, matheus wrote:
> On Tuesday, 25 October 2022 at 20:12:25 UTC, Paul Backus wrote:
>> Static arrays are value types.
What that means is, when we say float[3], there are just 3 floats
without any overhead.
>> Dynamic arrays are reference types.
That phrase can be confusing
I'm naturally getting a undefined identifier `s` error in the
return. Is there some way to refactor my code? I tried to
declare s outside of the else brackets like:
auto screen = executeShell(cmdLine);
auto s;
...
{
s = screen.output.findSplit("REG_SZ");
}
but that doesn
On Tuesday, 25 October 2022 at 20:27:18 UTC, Ali Çehreli wrote:
On 10/25/22 13:12, Paul Backus wrote:
> In order to create a copy of a static array
Although .dup works for static arrays as well, you meant
"dynamic array" and everyones knows it. :)
Yes; thank you for the correction. :)
On Tuesday, 25 October 2022 at 20:12:25 UTC, Paul Backus wrote:
On Tuesday, 25 October 2022 at 17:54:16 UTC, Salih Dincer wrote:
On Tuesday, 25 October 2022 at 17:18:35 UTC, Paul Backus wrote:
It's not a bug. They're pointing to the exact same instance
of `A` in memory:
I don't understand?
On 10/25/22 13:12, Paul Backus wrote:
> In order to create a copy of a static array
Although .dup works for static arrays as well, you meant "dynamic array"
and everyones knows it. :)
> with its own block of
> memory, separate from the original, you have to use the built-in `.dup`
> method:
On Tuesday, 25 October 2022 at 17:54:16 UTC, Salih Dincer wrote:
On Tuesday, 25 October 2022 at 17:18:35 UTC, Paul Backus wrote:
It's not a bug. They're pointing to the exact same instance of
`A` in memory:
I don't understand? So I don't understand why it causes
problems with dynamic
On 10/25/22 11:23, Steven Schveighoffer wrote:
>> Why do I say incorrect things like that? :)
> You were right actually.
As always! Now I'm confused. :o)
Ali
On 10/25/22 2:03 PM, Ali Çehreli wrote:
On 10/25/22 11:01, Ali Çehreli wrote:
> static arrays don't have .ptr to point
> to any member.
Why do I say incorrect things like that? :) Of course static arrays have
.ptr as well but that always point to their own body of N elements. They
own
On 10/25/22 11:01, Ali Çehreli wrote:
> static arrays don't have .ptr to point
> to any member.
Why do I say incorrect things like that? :) Of course static arrays have
.ptr as well but that always point to their own body of N elements. They
own their elements... I move away from the keyboard
On 10/25/22 10:54, Salih Dincer wrote:
> So I don't understand why it causes problems with
> dynamic arrays! So why is there nothing wrong with the static array in
> the example below?
The same rules as other uses of dynamic arrays...
> //A[] a = [A.init];/*
In that case, there is a
On Tuesday, 25 October 2022 at 17:18:35 UTC, Paul Backus wrote:
It's not a bug. They're pointing to the exact same instance of
`A` in memory:
I don't understand? So I don't understand why it causes problems
with dynamic arrays! So why is there nothing wrong with the
static array in the
struct A
{
int[] i;
}
struct B
{
A[] a = [A.init];
static B opCall()
{
return B.init;
}
}
void main()
{
auto b1 = B.init;
b1.writeln;
B b2 = B();
b2.writeln;
B b3;
b3.writeln;
}
> This fails in run time
Not anymore with the above code.
Ali
On Tuesday, 25 October 2022 at 16:52:48 UTC, Salih Dincer wrote:
On Tuesday, 25 October 2022 at 13:51:30 UTC, Andrey Zherikov
wrote:
Does the second piece of code shows a bug or my expectation is
not correct (and why if so)?
This is a bug:
```d
void main()
{
struct B
{
struct A
{
On Tuesday, 25 October 2022 at 13:51:30 UTC, Andrey Zherikov
wrote:
Does the second piece of code shows a bug or my expectation is
not correct (and why if so)?
This is a bug:
```d
void main()
{
struct B
{
struct A
{
int i = 10;
}
A[] a = [A.init];
}
B[2] b;
On Tuesday, 25 October 2022 at 14:53:50 UTC, Adam D Ruppe wrote:
On Tuesday, 25 October 2022 at 13:51:30 UTC, Andrey Zherikov
wrote:
A[] a = [A.init];
This is a problem - this is referring to a static array
instance, shared across all copies of B. You almost certainly
don't want this.
construction even when default ctor is
disabled:
```d
struct A
{
int[] i;
}
struct B
{
A[] a;
@disable this();
this(bool)
{
A[] a = [A.init];
}
}
void main()
{
auto b1 = B.init;
b1.a[0].i ~= 1;
b1.a ~= A.init;
b1.a[0].i ~= 11;
b1.a[1].i ~= 12
On 10/25/22 07:53, Adam D Ruppe wrote:
> On Tuesday, 25 October 2022 at 13:51:30 UTC, Andrey Zherikov wrote:
>> A[] a = [A.init];
>
> This is a problem - this is referring to a static array instance, shared
> across all copies of B. You almost certainly don't want this.
Agreed. It should be
On Tuesday, 25 October 2022 at 13:51:30 UTC, Andrey Zherikov
wrote:
A[] a = [A.init];
This is a problem - this is referring to a static array instance,
shared across all copies of B. You almost certainly don't want
this.
That B.a[0] is the *same object* across different
I have the following types (simplified version of my code):
```d
struct A
{
int[] i;
}
struct B
{
A[] a = [A.init];
}
```
This code:
```d
auto b1 = B.init;
b1.a[0].i ~= 1;
b1.a ~= A.init;
b1.a[0].i ~= 11;
b1.a[1].i ~= 12;
b1.writeln;
auto b2 = B();
b2
On Tuesday, 9 November 2021 at 19:30:20 UTC, tchaloupka wrote:
On Monday, 8 November 2021 at 23:26:39 UTC, tchaloupka wrote:
Bug or feature? :)
I've reported it in
https://issues.dlang.org/show_bug.cgi?id=22498.
It doesn't copy. It just destructs the same object twice... Ouch.
Change the
On Monday, 8 November 2021 at 23:26:39 UTC, tchaloupka wrote:
Bug or feature? :)
I've reported it in
https://issues.dlang.org/show_bug.cgi?id=22498.
{ int x; @disable this(this); }
unittest {
import core.lifetime : move;
auto a = A(5);
auto b = B(5);
a.move;
b.move;
assert(a == A(5));
assert(b == B(0));
}
```
Yes it should qualify so it should be cleaned out when moved.
When I change:
```D
auto ref unwrap(EX)(auto
core.lifetime : move;
auto a = A(5);
auto b = B(5);
a.move;
b.move;
assert(a == A(5));
assert(b == B(0));
}
```
On Tuesday, 9 November 2021 at 02:19:28 UTC, Stanislav Blinov
wrote:
On Monday, 8 November 2021 at 23:26:39 UTC, tchaloupka wrote:
```
auto gen() {
Foo f; // <--- this one
f.n = 42;
return value(f.move());
}
void main() {
Foo f;
f = gen().unwrap.m
On Monday, 8 November 2021 at 23:26:39 UTC, tchaloupka wrote:
```
auto gen() {
Foo f; // <--- this one
f.n = 42;
return value(f.move());
}
void main() {
Foo f;
f = gen().unwrap.move;
}
```
~this(0)
~this(0)
~this(0)
~this(42) <- this is
Lets have this code:
```D
import core.lifetime : forward;
import core.stdc.stdio;
import std.algorithm : move;
struct Value(T) {
private T storage;
this()(auto ref T val) {
storage = forward!val;
}
ref inout(T) get() inout {
return storage;
}
}
Value!T
;
this(Success value)
{
result = value;
}
this(Failure value)
{
result = value;
}
}
auto success(T)(T value)
{
return Result!T(Result!T.Success(value));
}
auto failure(string error)
{
return Result!void(Result!void.Failure(error));
}
auto f(int i)
{
return
t = Algebraic!(int, string) ;
void main()
{
auto x = true? Result("fish") : Result(6);
}
On Saturday, 7 November 2020 at 15:49:13 UTC, James Blachly wrote:
```
retval = i > 0 ? Success!int(i) : Failure("Sorry");
```
casting each to `Result` compiles, but is verbose:
```
return i > 0 ? cast(Result) Success!int(i) : cast(Result)
Failure("Sorry");
```
** Could someone more
On 11/6/20 5:51 AM, Andrey Zherikov wrote:
I have auto function 'f' that might return either an error (with some
text) or a result (with some value). The problem is that the type of the
error is not the same as the type of result so compilation fails.
...
How can I make the original code
On Saturday, 7 November 2020 at 01:50:15 UTC, Jesse Phillips
wrote:
On Friday, 6 November 2020 at 15:06:18 UTC, Andrey Zherikov
wrote:
On Friday, 6 November 2020 at 14:58:40 UTC, Jesse Phillips
wrote:
On Friday, 6 November 2020 at 14:20:40 UTC, Andrey Zherikov
wrote:
This issue seems hit the
On Friday, 6 November 2020 at 15:06:18 UTC, Andrey Zherikov wrote:
On Friday, 6 November 2020 at 14:58:40 UTC, Jesse Phillips
wrote:
On Friday, 6 November 2020 at 14:20:40 UTC, Andrey Zherikov
wrote:
This issue seems hit the inability to implicitly convert
custom types. May be it makes more
On Friday, 6 November 2020 at 20:05:36 UTC, Ferhat Kurtulmuş
wrote:
On Friday, 6 November 2020 at 10:51:20 UTC, Andrey Zherikov
wrote:
I have auto function 'f' that might return either an error
(with some text) or a result (with some value). The problem is
that the type of the error
On Friday, 6 November 2020 at 10:51:20 UTC, Andrey Zherikov wrote:
I have auto function 'f' that might return either an error
(with some text) or a result (with some value). The problem is
that the type of the error is not the same as the type of
result so compilation fails.
[...]
Sounds
On Friday, 6 November 2020 at 15:06:18 UTC, Andrey Zherikov wrote:
To clarify my statement:
Yes, Result!void and Result!int are different types but I
couldn't find a way to implicitly convert one to another.
You can't. Structs do not implicitly convert to each other,
templated or otherwise.
On Friday, 6 November 2020 at 14:58:40 UTC, Jesse Phillips wrote:
On Friday, 6 November 2020 at 14:20:40 UTC, Andrey Zherikov
wrote:
This issue seems hit the inability to implicitly convert
custom types. May be it makes more sense to ask in a separate
thread.
The return type must be the same
On Friday, 6 November 2020 at 14:20:40 UTC, Andrey Zherikov wrote:
On Friday, 6 November 2020 at 12:03:01 UTC, Paul Backus wrote:
You can't. Both return values have to have the same type,
which means the failure function has to be able to return more
than one type, which means it has to be a
On Friday, 6 November 2020 at 12:03:01 UTC, Paul Backus wrote:
You can't. Both return values have to have the same type, which
means the failure function has to be able to return more than
one type, which means it has to be a template.
This issue seems hit the inability to implicitly convert
On Friday, 6 November 2020 at 13:59:58 UTC, gbram wrote:
On Friday, 6 November 2020 at 12:03:01 UTC, Paul Backus wrote:
On Friday, 6 November 2020 at 10:51:20 UTC, Andrey Zherikov
wrote:
How can I make the original code compilable without
templatizing `failure` function?
You can't. Both
On Friday, 6 November 2020 at 12:03:01 UTC, Paul Backus wrote:
On Friday, 6 November 2020 at 10:51:20 UTC, Andrey Zherikov
wrote:
How can I make the original code compilable without
templatizing `failure` function?
You can't. Both return values have to have the same type, which
means the
On Friday, 6 November 2020 at 10:51:20 UTC, Andrey Zherikov wrote:
I can make it work if I add a type to `failure` function but
this remove brevity in usage:
-
auto failure(T)(string error)
{
return Result!T(Result!T.Failure(error));
}
auto f(int i)
{
return i >
I have auto function 'f' that might return either an error (with
some text) or a result (with some value). The problem is that the
type of the error is not the same as the type of result so
compilation fails.
Here is my code:
--
struct Result(T)
{
struct Success
On Friday, 9 October 2020 at 16:10:03 UTC, Ferhat Kurtulmuş wrote:
On Friday, 9 October 2020 at 15:49:31 UTC, Ferhat Kurtulmuş
wrote:
On Friday, 9 October 2020 at 00:19:20 UTC, Marcone wrote:
How auto convert Variant to required function arguments?
import std.variant;
import std.stdio
On Friday, 9 October 2020 at 15:49:31 UTC, Ferhat Kurtulmuş wrote:
On Friday, 9 October 2020 at 00:19:20 UTC, Marcone wrote:
How auto convert Variant to required function arguments?
import std.variant;
import std.stdio;
Variant a;
int mul2(Variant b){
int c = *b.peek!(int);
return
On Friday, 9 October 2020 at 00:19:20 UTC, Marcone wrote:
How auto convert Variant to required function arguments?
import std.variant;
import std.stdio;
Variant a;
int mul2(Variant b){
int c = *b.peek!(int);
return 2*c;
}
int mul3(int b){
return 3*b;
}
void main()
{
a = 5
How auto convert Variant to required function arguments?
On Wednesday, 2 September 2020 at 21:40:59 UTC, Steven
Schveighoffer wrote:
What they can do is template the `this` parameter. Then if the
underlying range supports calling that way, it will work,
otherwise it won't.
using `template this` should be compatible with the existing
code I would
On 9/2/20 5:23 PM, SimonN wrote:
Hi,
About this issue in Phobos:
https://issues.dlang.org/show_bug.cgi?id=21216
SortedRange.empty should be const, .front should be inout
Just adding const/inout to SortedRange's methods won't be enough; if we
add const/inout here, then many other Phobos ranges
Hi,
About this issue in Phobos:
https://issues.dlang.org/show_bug.cgi?id=21216
SortedRange.empty should be const, .front should be inout
Just adding const/inout to SortedRange's methods won't be enough;
if we add const/inout here, then many other Phobos ranges need to
become
Debian 8.3.0-6, dst[]= generates a range
error
auto a = [1, 2, 3];
auto b = [4, 5, 6];
int[] dst = new int[4]; // note the extra element
dst[] = a[] + b[];
writeln(dst[3]);
On 8/3/20 3:22 PM, Bruce Carneal wrote:
Thanks Steve (and Chad). Summary: underspecified, varying behavior
across versions, buggy.
Steve, what's the best way for me to report this? Are spec issues
lumped in with the other bugzilla reports?
Yep. You can file under dlang.org with the spec
On Monday, 3 August 2020 at 18:55:36 UTC, Steven Schveighoffer
wrote:
On 8/2/20 1:31 PM, Bruce Carneal wrote:
import std;
void f0(int[] a, int[] b, int[] dst) @safe {
dst[] = a[] + b[];
}
[snip of auto-vectorization example]
I was surprised that f0 ran just fine with a.length
(dst.length == minLen);
}
I was surprised that f0 ran just fine with a.length and b.length geq
dst.length. Is that a bug or a feature?
Assuming it's a feature, are f0 and f1 morally equivalent? I ask
because f1 auto-vectorizes in ldc while f0 does not. Not sure why. As
a guess I'd say
..minLen];
assert(dst.length == minLen);
}
I was surprised that f0 ran just fine with a.length and
b.length geq dst.length. Is that a bug or a feature?
Assuming it's a feature, are f0 and f1 morally equivalent? I
ask because f1 auto-vectorizes in ldc while f0 does not. Not
sure why
that f0 ran just fine with a.length and b.length
geq dst.length. Is that a bug or a feature?
Assuming it's a feature, are f0 and f1 morally equivalent? I ask
because f1 auto-vectorizes in ldc while f0 does not. Not sure
why. As a guess I'd say that the front end doesn't hoist bounds
checks in f0
by actually forwarding arguments to it
(because a function template may have auto ref parameters).
Steven's issue report doesn't account for templates, nor
overloading, and correctly testing the latter would pretty much
require you to match argument types and ref-ness by hand anyway
(yuck).
On 12/6/20 20:34, Stanislav Blinov wrote:
On Friday, 12 June 2020 at 17:50:43 UTC, Arafel wrote:
All in all, I still think something like `__traits(isRef,return)`
would still be worth adding! After all the compiler already has all
the information, so it's just about exposing it. I'm trying to
On Friday, 12 June 2020 at 17:50:43 UTC, Arafel wrote:
All in all, I still think something like
`__traits(isRef,return)` would still be worth adding! After all
the compiler already has all the information, so it's just
about exposing it. I'm trying to think of a library solution,
but I find
On 12/6/20 18:15, Paul Backus wrote:
I think I have something that works:
ref int foo();
int bar();
enum isLvalue(string expr) = q{
__traits(compiles, (auto ref x) {
static assert(__traits(isRef, x));
}(} ~ expr ~ q{))
};
pragma(msg, mixin(isLvalue!"foo()")
On Friday, 12 June 2020 at 14:56:41 UTC, Arafel wrote:
Hi all,
I'm hitting a problem that it's making crazy... is there any
way to find out if the return of an `auto ref` function is
actually ref or not?
So, according to the documentation [1] it depends on the return
expressions... however
Hi all,
I'm hitting a problem that it's making crazy... is there any way to find
out if the return of an `auto ref` function is actually ref or not?
So, according to the documentation [1] it depends on the return
expressions... however in my case I'm implementing `opDispatch` in a
wrapper
On Thursday, 4 June 2020 at 04:48:22 UTC, bauss wrote:
On Wednesday, 3 June 2020 at 11:54:57 UTC, Виталий Фадеев wrote:
On Tuesday, 2 June 2020 at 20:08:09 UTC, bauss wrote:
What happens if you have the same symbol in multiple modules?
Ex. two libraries that implement symbols with same name.
On Wednesday, 3 June 2020 at 11:54:57 UTC, Виталий Фадеев wrote:
On Tuesday, 2 June 2020 at 20:08:09 UTC, bauss wrote:
What happens if you have the same symbol in multiple modules?
Ex. two libraries that implement symbols with same name.
First module will inserted.
Is there a way to be
On Tuesday, 2 June 2020 at 20:08:09 UTC, bauss wrote:
What happens if you have the same symbol in multiple modules?
Ex. two libraries that implement symbols with same name.
First module will inserted.
Is there a way to be selective?
I want it too! :)
And what about keyboard shortcut?
On Monday, 1 June 2020 at 17:28:16 UTC, Johannes Loher wrote:
On Monday, 1 June 2020 at 16:18:44 UTC, Виталий Фадеев wrote:
[...]
Demanding stuff usually doesn't work in this community. The
usual answer is something like this: If you care about this,
implement it yourself or pay somebody to
On Tuesday, 2 June 2020 at 06:00:10 UTC, Виталий Фадеев wrote:
On Monday, 1 June 2020 at 18:55:03 UTC, Paul Backus wrote:
On Monday, 1 June 2020 at 16:18:44 UTC, Виталий Фадеев wrote:
I do it!
https://github.com/vitalfadeev/SublimeDlangAutoImport
What happens if you have the same symbol in
On Tuesday, 2 June 2020 at 06:00:10 UTC, Виталий Фадеев wrote:
On Monday, 1 June 2020 at 18:55:03 UTC, Paul Backus wrote:
On Monday, 1 June 2020 at 16:18:44 UTC, Виталий Фадеев wrote:
I do it!
https://github.com/vitalfadeev/SublimeDlangAutoImport
Cool. I dont use classe but I see how this
On Tuesday, 2 June 2020 at 06:00:10 UTC, Виталий Фадеев wrote:
On Monday, 1 June 2020 at 18:55:03 UTC, Paul Backus wrote:
On Monday, 1 June 2020 at 16:18:44 UTC, Виталий Фадеев wrote:
I do it!
https://github.com/vitalfadeev/SublimeDlangAutoImport
Great! You should make a post about it in
On Monday, 1 June 2020 at 18:55:03 UTC, Paul Backus wrote:
On Monday, 1 June 2020 at 16:18:44 UTC, Виталий Фадеев wrote:
I do it!
https://github.com/vitalfadeev/SublimeDlangAutoImport
On Monday, 1 June 2020 at 16:18:44 UTC, Виталий Фадеев wrote:
I want Sublime D auto import !
When typing code like this:
class Uno : IStylable
{
//
}
I want will be auto added "import IStylable" at begin of file.
Like this:
import ui.istylable :
On Monday, 1 June 2020 at 16:18:44 UTC, Виталий Фадеев wrote:
I want Sublime D auto import !
When typing code like this:
class Uno : IStylable
{
//
}
I want will be auto added "import IStylable" at begin of file.
Like this:
import ui.istylable :
I want Sublime D auto import !
When typing code like this:
class Uno : IStylable
{
//
}
I want will be auto added "import IStylable" at begin of file.
Like this:
import ui.istylable : IStylable;
class Uno : IStylable
{
//
}
On Sunday, 10 May 2020 at 01:15:58 UTC, Anonymouse wrote:
On Sunday, 10 May 2020 at 00:33:07 UTC, NaN wrote:
Ie something like..
auto Foo(T)(auto ref T x)
{
static if (isByRef(x))
{
}
else
{
}
}
__traits(isRef, x)
Thanks :)
On Sunday, 10 May 2020 at 00:33:07 UTC, NaN wrote:
Ie something like..
auto Foo(T)(auto ref T x)
{
static if (isByRef(x))
{
}
else
{
}
}
__traits(isRef, x)
Ie something like..
auto Foo(T)(auto ref T x)
{
static if (isByRef(x))
{
}
else
{
}
}
On Tuesday, 21 April 2020 at 21:36:57 UTC, Marcone wrote:
When I create a module, for exemple mymodule.d and import im my
main program using "import mymodule" I need add mymodule.d in
DMD command line manually. How can make it automatic?
dmd -i
When I create a module, for exemple mymodule.d and import im my
main program using "import mymodule" I need add mymodule.d in DMD
command line manually. How can make it automatic?
find it readable.
There are many waypoints on the readability <==> performance
axis. If ispc works for you along that axis, great!
I find SIMT code readability better than SIMD but a little
worse than auto-vectorizable kernels. Hugely better
performance though for less effort tha
1 - 100 of 695 matches
Mail list logo
