Re: Types of lambda args
On Mon, Aug 17, 2020 at 12:20:24AM +, Cecil Ward via Digitalmars-d-learn
wrote:
> In a lambda, how do we know what types the arguments are? In something
> like
> (x) => x * x
It's implemented as a template, whose argument types are inferred based
on usage context.
> - there I just don’t get it at all. Can you write
> (uint x) => x * x
Of course you can.
> I’m lost.
[...]
If you're ever unsure of what the inferred type(s) are, you can do
replace the lambda with something like this:
(x) { pragma(msg, typeof(x)); return x*x }
which will print out the inferred type when the compiler instantiates
the lambda.
T
--
Customer support: the art of getting your clients to pay for your own
incompetence.
Re: Cannot call @system funciton (stdout)
On Sunday, 16 August 2020 at 18:13:07 UTC, Anonymouse wrote: On Sunday, 16 August 2020 at 10:07:02 UTC, Simen Kjærås wrote: On Saturday, 15 August 2020 at 23:59:36 UTC, Joel wrote: [...] First, what's wrong with using writeln and friends instead of directly mucking about with stdout? :p Just as a drive-by comment, the main stdio thing I came across that I couldn't do from within @safe was stdout.flush(), which I need to call manually for Cygwin terminals and some terminals embedded in editors (vscode). If someone knows why, please tell me. Yeah, that's probably the only thing I've used 'stdout' for so far - flush.
Re: Types of lambda args
On 8/16/20 8:27 PM, Adam D. Ruppe wrote: On Monday, 17 August 2020 at 00:20:24 UTC, Cecil Ward wrote: In a lambda, how do we know what types the arguments are? In something like (x) => x * x In that the compiler figures it out from usage context. So if you pass it to a int delegate(int), it will figure x must be int. It's actually a template, with some special benefits. It relies on IFTI to work. -Steve
Re: Types of lambda args
On Monday, 17 August 2020 at 00:20:24 UTC, Cecil Ward wrote: In a lambda, how do we know what types the arguments are? In something like (x) => x * x In that the compiler figures it out from usage context. So if you pass it to a int delegate(int), it will figure x must be int. - there I just don’t get it at all. Can you write (uint x) => x * x yeah you can always add more info if you like.
Types of lambda args
In a lambda, how do we know what types the arguments are? In something like (x) => x * x - there I just don’t get it at all. Can you write (uint x) => x * x I’m lost. Cecil Ward.
Re: Autodecode?
On 8/16/20 4:53 PM, JN wrote: Related to this thread: https://forum.dlang.org/post/xtjzhkvszdiwvrmry...@forum.dlang.org I don't want to hijack it with my newbie questions. What is autodecode and why is it such a big deal? From what I've seen it's related to handling Unicode characters? And D has the wrong defaults? Aside from what others have said, autodecode isn't really terrible as a default. But what IS terrible is the inconsistency. Phobos says char[] is not an array, but the language does. e.g.: char[] example; static assert(!hasLength!(typeof(example))); // Phobos: no length here! auto l = example.length; // dlang: um... yes, there is. static assert(!hasIndexing!(typeof(example))); // P: no index support! auto e = example[0]; // D: yes, you can index. And probably my favorite WTF: static assert(is(ElementType!(typeof(example)) == dchar)); // P: char is a range of dchar! foreach(e; example) static assert(is(typeof(e)) == char)); // D: nope, it's an array of char This leads to all kinds of fun stuff. Like try chaining together several char[] arrays, and then converting the result into an array. Surprise! it's a dchar[], and you just wasted a bunch of CPU cycles decoding them, not to mention the RAM to store it. But then Phobos, as it's telling you that all these things aren't true, then goes behind your back and implements all kinds of special cases to deal with these narrow strings *using the array interfaces* because it performs better. We will be much better off to be done with autodecoding. And for many cases, autodecoding is just fine! Most of the time, you only care about the entire string and not what it's made of. Many other languages do "autodecoding", and in fact the string type is opaque. But then it gives you ways to use it that aren't silly (like concatenating 2 strings knows what the underlying types are and figures out the most efficient way possible). If `string` was a custom type and not an array, we probably wouldn't have so many issues with it. -Steve
Re: Autodecode?
On Sunday, 16 August 2020 at 20:53:41 UTC, JN wrote: Related to this thread: https://forum.dlang.org/post/xtjzhkvszdiwvrmry...@forum.dlang.org I don't want to hijack it with my newbie questions. What is autodecode and why is it such a big deal? From what I've seen it's related to handling Unicode characters? And D has the wrong defaults? For built-in arrays, the range primitives (empty, front, popFront, etc.) are implemented as free functions in the standard-library module `std.range.primitives`. [1] For most arrays, these work the way you'd expect: empty checks if the array is empty, front returns `array[0]`, and popFront does `array = array[1..$]`. But for char[] and wchar[] specifically, `front` and `popFront` work differently. They treat the arrays as UTF-8 or UTF-16 encoded Unicode strings, and return/pop the first *code point* instead of the first *code unit*. In other words, they "automatically decode" the array. This has a number of annoying consequences. New users get mysterious template errors in the middle of range pipelines complaining about a mismatch between `dchar` (the type of a code point) and `char` (the type of a code unit). Generic code that deals with arrays has to add special cases for char[] and wchar[]. Strings don't work correctly in betterC because Unicode decoding can throw an exception. [2] If you search the forums, you'll find plenty more complaints. The intent behind autodecoding was to help programmers avoid common Unicode-related errors by doing "the right thing" by default. The problem is that (a) decoding to code points isn't always the right thing, and (b) autodecoding ended up causing a bunch of additional problems of its own. [1] http://dpldocs.info/experimental-docs/std.range.primitives.html [2] https://issues.dlang.org/show_bug.cgi?id=20139
Re: Autodecode?
On Sunday, 16 August 2020 at 20:53:41 UTC, JN wrote: Related to this thread: https://forum.dlang.org/post/xtjzhkvszdiwvrmry...@forum.dlang.org I don't want to hijack it with my newbie questions. What is autodecode and why is it such a big deal? From what I've seen it's related to handling Unicode characters? And D has the wrong defaults? https://forum.dlang.org/thread/qitnkf$2736$1...@digitalmars.com?page=1
Autodecode?
Related to this thread: https://forum.dlang.org/post/xtjzhkvszdiwvrmry...@forum.dlang.org I don't want to hijack it with my newbie questions. What is autodecode and why is it such a big deal? From what I've seen it's related to handling Unicode characters? And D has the wrong defaults?
Re: Cannot call @system funciton (stdout)
On Sunday, 16 August 2020 at 10:07:02 UTC, Simen Kjærås wrote: On Saturday, 15 August 2020 at 23:59:36 UTC, Joel wrote: ../../JMiscLib/source/jmisc/base.d(176,2): Error: @safe function jmisc.base.upDateStatus!string.upDateStatus cannot call @system function std.stdio.makeGlobal!"core.stdc.stdio.stdout".makeGlobal /Library/D/dmd/src/phobos/std/stdio.d(4837,20): std.stdio.makeGlobal!"core.stdc.stdio.stdout".makeGlobal is declared here I got around it by avoiding 'stdout'. First, what's wrong with using writeln and friends instead of directly mucking about with stdout? :p Just as a drive-by comment, the main stdio thing I came across that I couldn't do from within @safe was stdout.flush(), which I need to call manually for Cygwin terminals and some terminals embedded in editors (vscode). If someone knows why, please tell me.
Re: Cannot call @system funciton (stdout)
On 8/16/20 6:07 AM, Simen Kjærås wrote:
On Saturday, 15 August 2020 at 23:59:36 UTC, Joel wrote:
../../JMiscLib/source/jmisc/base.d(176,2): Error: @safe function
jmisc.base.upDateStatus!string.upDateStatus cannot call @system
function std.stdio.makeGlobal!"core.stdc.stdio.stdout".makeGlobal
/Library/D/dmd/src/phobos/std/stdio.d(4837,20):
std.stdio.makeGlobal!"core.stdc.stdio.stdout".makeGlobal is declared here
I got around it by avoiding 'stdout'.
First, what's wrong with using writeln and friends instead of directly
mucking about with stdout? :p
stdout is __gshared, so it's available on any thread at any time. That's
not @safe, so it's @system.
If you know you're not using stdout from multiple threads, or don't care
(it might be perfectly safe even though it's possible to misuse), you
can use this code:
@property File trustedStdout() @trusted
{
return stdout;
}
That's a @trusted wrapper that you can call from @safe code. It's not
actually safe though, as multiple threads could be using trustedStdout
at the same time. In many use cases, this is unlikely to matter, but
it's wroth keeping in mind.
Technically, there's nothing unsafe about reading stdout, as long as you
are not setting it. Otherwise, writeln wouldn't be @safe (as all it does
is call a private trustedStdout).
The whole thing is messy IMO, and should be revisited.
-Steve
Re: Cannot call @system funciton (stdout)
On Saturday, 15 August 2020 at 23:59:36 UTC, Joel wrote:
../../JMiscLib/source/jmisc/base.d(176,2): Error: @safe
function jmisc.base.upDateStatus!string.upDateStatus cannot
call @system function
std.stdio.makeGlobal!"core.stdc.stdio.stdout".makeGlobal
/Library/D/dmd/src/phobos/std/stdio.d(4837,20):
std.stdio.makeGlobal!"core.stdc.stdio.stdout".makeGlobal is
declared here
I got around it by avoiding 'stdout'.
First, what's wrong with using writeln and friends instead of
directly mucking about with stdout? :p
stdout is __gshared, so it's available on any thread at any time.
That's not @safe, so it's @system.
If you know you're not using stdout from multiple threads, or
don't care (it might be perfectly safe even though it's possible
to misuse), you can use this code:
@property File trustedStdout() @trusted
{
return stdout;
}
That's a @trusted wrapper that you can call from @safe code. It's
not actually safe though, as multiple threads could be using
trustedStdout at the same time. In many use cases, this is
unlikely to matter, but it's wroth keeping in mind.
--
Simen
