On Tue, Jun 23, 2020 at 03:25:55AM +, Stanislav Blinov via
Digitalmars-d-learn wrote:
> On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis wrote:
>
> > As things stand, uncopyable ranges aren't really a thing, and common
> > range idiomns rely on ranges being copyable.
>
> Which
Is there a preferred idiom in D for flagging special conditions
when returning from a function call? Here "special conditions"
refers to expected situations (e.g. reaching the end of
something, like EOF) rather than outright errors (so
exception-try-catch is inappropriate).
I've come across
On 6/22/20 2:37 PM, mw wrote:
> On Monday, 22 June 2020 at 20:58:58 UTC, Ali Çehreli wrote:
>
>> Others have other explanations for this but my understanding is about
>> exception safety: If it changed internal state and returned the front
>> object, you would no be able to make a function like
On Monday, June 22, 2020 9:25:55 PM MDT Stanislav Blinov via Digitalmars-d-
learn wrote:
> On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis wrote:
> > As things stand, uncopyable ranges aren't really a thing, and
> > common range idiomns rely on ranges being copyable.
>
> Which idioms
On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis wrote:
As things stand, uncopyable ranges aren't really a thing, and
common range idiomns rely on ranges being copyable.
Which idioms are those? I mean, genuine idioms, not design flaws
like e.g. references.
We'd need some major
On Mon, Jun 22, 2020 at 08:53:22PM -0600, Jonathan M Davis via
Digitalmars-d-learn wrote:
[...]
> Exactly. It's because of issues like this that generic, range-based
> functions need to be tested with a variety of range types - including
> reference types. Without that, bugs are routinely missed.
Should it always be 53? or it can be 64, when?
Thank you
On Monday, June 22, 2020 3:33:08 PM MDT H. S. Teoh via Digitalmars-d-learn
wrote:
> On Mon, Jun 22, 2020 at 09:11:07PM +, Stanislav Blinov via Digitalmars-
d-learn wrote:
> > That is not true. Copying of forward ranges is absolutely fine. It's
> > what the current `save()` primitive is
On Monday, June 22, 2020 3:11:07 PM MDT Stanislav Blinov via Digitalmars-d-
learn wrote:
> On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote:
> > You're unlikely to find much range-based code that does that
> > and there really isn't much point in doing that. Again, copying
> > isn't
On Monday, June 22, 2020 3:38:02 PM MDT Paul Backus via Digitalmars-d-learn
wrote:
> On Monday, 22 June 2020 at 21:33:08 UTC, H. S. Teoh wrote:
> > Jonathan is coming from the POV of generic code. The problem
> > with move leaving the original range in its .init state isn't
> > so much that it
On Monday, 22 June 2020 at 21:33:08 UTC, H. S. Teoh wrote:
Don't be shocked when you find out how many Phobos ranges have
.init states that are invalid (e.g., non-empty, but .front and
.popFront will crash / return invalid values).
Which ones?
Jonathan is coming from the POV of generic
On Monday, June 22, 2020 3:46:57 PM MDT Per Nordlöw via Digitalmars-d-learn
wrote:
> Has anybody written a procedure for creating a temporary file in
> a race-free manner?
>
> And why has such a procedure not already been added to std.file
> when std.file.tempDir has?
>
> See:
On Monday, 22 June 2020 at 21:46:57 UTC, Per Nordlöw wrote:
Has anybody written a procedure for creating a temporary file
in a race-free manner?
And why has such a procedure not already been added to std.file
when std.file.tempDir has?
See: https://dlang.org/library/std/file/temp_dir.html
On Monday, 22 June 2020 at 10:26:12 UTC, aberba wrote:
It would be a one-liner if it was an api. Such utility APIs are
quite missing in D.
Um, You are right.
How about putting them together into a package?
Well, this is an inspiration to me. Let me try. :)
On Monday, 22 June 2020 at 21:27:12 UTC, Steven Schveighoffer
wrote:
auto line = range.front;
range.popFront; // pop immediately
This is a bad idea, once you popFront, the original front is
possibly invalid (and technically is the case for byLine).
In this case, it's caused by
On Monday, 22 June 2020 at 21:22:10 UTC, H. S. Teoh wrote:
On Mon, Jun 22, 2020 at 08:51:49PM +, mw via
Digitalmars-d-learn wrote: [...]
>auto line = range.front;
>range.popFront; // pop immediately
[...]
This is dangerous, because it assumes .front is not invalidated
by
Has anybody written a procedure for creating a temporary file in
a race-free manner?
And why has such a procedure not already been added to std.file
when std.file.tempDir has?
See: https://dlang.org/library/std/file/temp_dir.html
On Monday, 22 June 2020 at 21:33:08 UTC, H. S. Teoh wrote:
Jonathan is coming from the POV of generic code. The problem
with move leaving the original range in its .init state isn't
so much that it will crash or anything (even though as you said
that does indicate a flaw in the range's
On Monday, 22 June 2020 at 20:58:58 UTC, Ali Çehreli wrote:
Others have other explanations for this but my understanding is
about exception safety: If it changed internal state and
returned the front object, you would no be able to make a
function like popFront() strongly exception safe.
On Monday, June 22, 2020 3:10:28 PM MDT kinke via Digitalmars-d-learn wrote:
> On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote:
> > [...]
>
> That's why I put the struct in parantheses. Moving a class ref
> makes hardly any sense, but I've also never written a *class* to
>
On Mon, Jun 22, 2020 at 09:11:07PM +, Stanislav Blinov via
Digitalmars-d-learn wrote:
> On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote:
[...]
> > And moving doesn't fix anything, since the original variable is
> > still there (just in its init state, which would still be
On 6/22/20 4:49 PM, mw wrote:
On Monday, 22 June 2020 at 20:46:30 UTC, mw wrote:
On Monday, 22 June 2020 at 20:00:50 UTC, Steven Schveighoffer wrote:
I wouldn't recommend it, instead do a while loop:
auto range = File(fn).byLine;
while(!range.empty)
{
auto line = range.front;
On Mon, Jun 22, 2020 at 08:51:49PM +, mw via Digitalmars-d-learn wrote:
[...]
> >auto line = range.front;
> >range.popFront; // pop immediately
[...]
This is dangerous, because it assumes .front is not invalidated by
.popFront. It will not work, for example, with byLine because
On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote:
You're unlikely to find much range-based code that does that
and there really isn't much point in doing that. Again, copying
isn't the problem. It's using the original after making the
copy that's the problem.
Copy *is* the
On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote:
[...]
That's why I put the struct in parantheses. Moving a class ref
makes hardly any sense, but I've also never written a *class* to
represent a range. Moving is the no-brainer solution for
transferring ownership of struct
On 6/22/20 1:46 PM, mw wrote:
> so `front` is peek, and `popFront` is the pop action whose return type
> is `void`, why we need two *separate* calls instead of just let
> `popFront` return T
Others have other explanations for this but my understanding is about
exception safety: If it changed
On Monday, 22 June 2020 at 20:49:55 UTC, mw wrote:
On Monday, 22 June 2020 at 20:46:30 UTC, mw wrote:
On Monday, 22 June 2020 at 20:00:50 UTC, Steven Schveighoffer
wrote:
I wouldn't recommend it, instead do a while loop:
auto range = File(fn).byLine;
while(!range.empty)
{
auto line =
On Monday, June 22, 2020 1:41:34 PM MDT kinke via Digitalmars-d-learn wrote:
> On Monday, 22 June 2020 at 19:03:44 UTC, Jonathan M Davis wrote:
> > in practice, that means that generic code cannot use a range
> > once it's been copied
>
> Translating to a simple rule-of-thumb: never copy a
On Monday, 22 June 2020 at 20:46:30 UTC, mw wrote:
On Monday, 22 June 2020 at 20:00:50 UTC, Steven Schveighoffer
wrote:
I wouldn't recommend it, instead do a while loop:
auto range = File(fn).byLine;
while(!range.empty)
{
auto line = range.front;
if(someCond(line)) {
On Monday, 22 June 2020 at 20:00:50 UTC, Steven Schveighoffer
wrote:
I wouldn't recommend it, instead do a while loop:
auto range = File(fn).byLine;
while(!range.empty)
{
auto line = range.front;
if(someCond(line)) {
range.popFrontN(n);
} else {
regularProcess(line);
On Monday, 22 June 2020 at 19:55:29 UTC, mw wrote:
Yes, in the same order and of the same length.
Can we add this information to the doc? to make it clear to the
user:
https://dlang.org/library/std/traits.html
It's pretty clear in that doc already:
alias FieldNameTuple(T) =
If you are referring to the next line, not the next n lines,
that's a simple `continue;` statement.
On Monday, 22 June 2020 at 20:02:22 UTC, kinke wrote:
If you are referring to the next line, not the next n lines,
that's a simple `continue;` statement.
[Please discard, that'd obviously be skipping the *current* line.]
On 6/22/20 3:53 PM, mw wrote:
Hi,
I need this logic:
```
auto range = File(fn).byLine();
foreach (line; range) {
if (comeCond(line)) {
// skip the next n line
// and continue the foreach loop from the (n+1) line
} else {
regularProcess(line);
}
}
```
Is it possible
On Saturday, 20 June 2020 at 20:42:03 UTC, Stanislav Blinov wrote:
On Saturday, 20 June 2020 at 20:17:54 UTC, mw wrote:
Are their returned value, i.e the field names and their types
are always in the same order, and of the same length?
If they are not, how to get sync-ed pairs (name, type)?
On Monday, 22 June 2020 at 19:41:22 UTC, Vlad wrote:
Usually, when you connect c++/c, you have header files so you
can call functions from Objective-C/swift code. We need
something similar.
There's a pretty recent -HC switch to generate C++ headers from
`extern(C++)` declarations. Not sure
Hi,
I need this logic:
```
auto range = File(fn).byLine();
foreach (line; range) {
if (comeCond(line)) {
// skip the next n line
// and continue the foreach loop from the (n+1) line
} else {
regularProcess(line);
}
}
```
Is it possible to do this in a foreach loop?
If
On Monday, 22 June 2020 at 18:40:21 UTC, Kagamin wrote:
If you want to use them from D, you need those classes and
methods declared in the D language, in text.
We want to use compiled D as a library in a iOS swift project.
Usually, when you connect c++/c, you have header files so you can
On Monday, 22 June 2020 at 19:03:44 UTC, Jonathan M Davis wrote:
in practice, that means that generic code cannot use a range
once it's been copied
Translating to a simple rule-of-thumb: never copy a (struct)
range, always move.
On Monday, June 22, 2020 10:59:45 AM MDT kinke via Digitalmars-d-learn wrote:
> If copying a range is considered to be generally unsafe and a
> common pitfall (vs. the save() abomination), maybe range-foreach
> shouldn't allow any lvalue ranges in the 1st place, thus not
> making any copies and
On Monday, 22 June 2020 at 14:27:18 UTC, Steven Schveighoffer
wrote:
I'm sure if there is a clib that doesn't work with this, it is
a bug with druntime, and should be addressed. I don't know
enough about the exact functionality to be able to write such a
bug report, but you probably should
If you want to use them from D, you need those classes and
methods declared in the D language, in text.
On 6/21/20 5:52 AM, adnan338 wrote:
I am trying to figure out how to prevent this data race.
I still like the std.concurrency method I used here:
https://forum.dlang.org/post/rkitcprqvslexgqaf...@forum.dlang.org
The only difference is that your individual progresses are from 0% to
100%.
On Monday, 22 June 2020 at 16:25:11 UTC, Jonathan M Davis wrote:
The reason that foreach copies the range is simply due to how
the code is lowered. e.g.
foreach(e; range)
{
}
essentially becomes
for(auto r = range; !r.empty; r.popFront())
{
auto e = r.front;
}
On Sunday, June 21, 2020 2:25:37 PM MDT kinke via Digitalmars-d-learn wrote:
> A foreach over a custom range makes an initial copy, so that the
> original range is still usable after the foreach (not empty).
No, it's not so that the range will be useable afterwards. In fact, for
generic code, you
On 6/22/20 10:36 AM, Per Nordlöw wrote:
On Monday, 22 June 2020 at 14:10:15 UTC, Mike Parker wrote:
https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md
The spec says:
"
The only place a refcounted Throwable is ever created is when the
following statement is in the user code:
On Monday, 22 June 2020 at 14:10:15 UTC, Mike Parker wrote:
https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md
The spec says:
"
The only place a refcounted Throwable is ever created is when the
following statement is in the user code:
throw new E(string);
"
What other typical
I have a static library (.a) compiled with LDC for iOS platform.
But I can't figure out how to correctly connect it to the project
and call its functions. I've already linked binary with library
to the project but IDE still doesn't see its classes and methods.
Do I need to do some additional
On 6/22/20 10:05 AM, IGotD- wrote:
This seems do some atomic operation preventing the D File class for
stdio not to be initialized several times. I'm not quite sure if this is
global or per thread but I guess it is for the entire process. For some
reason the std File classes are never
On Monday, 22 June 2020 at 13:59:22 UTC, Per Nordlöw wrote:
I can't find any docs on DIP-1008. The link
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1008.md
given in the release notes here
Ref: https://dlang.org/changelog/2.079.0.html#dip1008
is broken.
On Monday, 22 June 2020 at 13:59:22 UTC, Per Nordlöw wrote:
I can't find any docs on DIP-1008. The link
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1008.md
is broken.
Found the postponed spec here:
https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md
I've done some adaptations to druntime for another C library that
isn't currently supported. Obtaining the FILE* structure of the
clib is done via a function call rather than global variables.
However this function call is never triggered when issuing a
writeln function call. The FILE*
Under what circumstances is exception throwing currently `@nogc`
if the dmd flag `-dip1008` is used?
For instance in code such as:
void main() @nogc
{
throw new Exception("I'm @nogc now");
}
Are all exceptions forced to be statically allocated when
-dip1008 is used or can exception
On Monday, 22 June 2020 at 09:06:35 UTC, Jacob Carlborg wrote:
String **literals** have a terminating null character, to help
with integrating with C functions. But this null character will
disappear when manipulating strings.
You cannot assume that a function parameter of type `string`
On 6/21/20 10:04 PM, user1234 wrote:
On Monday, 22 June 2020 at 01:47:49 UTC, repr-man wrote:
Is there any way to pass an unknown number of slices into a function?
I'm trying to do something along the lines of:
void func(T)(T[] args...)
{
//...
}
That wasn't working,
[...]
Thanks for
On Monday, 22 June 2020 at 02:16:52 UTC, user1234 wrote:
[...]
Maybe that the spec is a bit vague as it doesn't mention that
[...]
A vague place in a spec is usually called "Dark Corner" and the
functionality then marked as "Implementation defined".
But this mark is missing here.
And
On Saturday, 20 June 2020 at 19:39:56 UTC, Vinod K Chandran wrote:
On Saturday, 20 June 2020 at 13:46:05 UTC, Dennis wrote:
Thanks a lot. Well, i thought it should be a one liner like-
Clipboard.SetText(sText)
But after reading your reply, i realized that this is D, not a
scripting language.
On Monday, 22 June 2020 at 04:08:10 UTC, Denis wrote:
The terminating null character was one of the reasons I thought
strings were different from char arrays. Now I know better.
String **literals** have a terminating null character, to help
with integrating with C functions. But this null
58 matches
Mail list logo
