On Thursday, 4 June 2020 at 08:38:59 UTC, Jacob Carlborg wrote:
> On Wednesday, 3 June 2020 at 11:22:23 UTC, Stefan Koch wrote:
>> AND the user probably would rather have written a loop, but was forced by the language to use recursion.
>
> That's definitely true.
>
>> I will continue on type functions; if the conservative approaches don't work out.
>
> I hope we can get type functions.
>
> --
> /Jacob Carlborg

Well to be completely honest type functions do look cool.
But they to have a their own set of problems.
I designed them so it would be impossible to "abuse" them.
I did that by putting a restriction in that would disallow them from generating symbols.
And that does work and greatly simplifies the implementation.
However, it also so means that they can't be used in many places that you would like to use them.
For example creating a std.typecons.Tuple is impossible with type functions alone.
For such a task they can only be used to reduce the intermediate symbols within a template.
Which I fear will lead to some frustration.
Also you would need to rewrite your entire reflection framework to use typefunctions.
For that to be feasible new __traits have to be introduced.
.....

All in all even though the feature alone is not that heavy, it will need major additions to be useful.
I cannot do this alone.
The way I see it; If Walter is not in the boat the boat will not get anywhere.
It's to heavy for me to move by myself.

On Wednesday, 3 June 2020 at 21:01:48 UTC, Steven Schveighoffer wrote:

> But the question above is still unanswered -- writeln receives a string as an immutable(char)[], and doesn't know that it's from a literal.

Perhaps add an overload that takes `const(char)*`? Here's an example:

string foo(T...)(T args) // signature of `writeln`
{
    return "...";
}

string foo(const(char)* value)
{
    return "foo";
}

void main()
{
    assert(foo("bar") == "foo");
}

The above assertion pass. That means the compiler prefers the version with `const(char)*` for string literals in favor over the template version.

--
/Jacob Carlborg

On Wednesday, 3 June 2020 at 11:22:23 UTC, Stefan Koch wrote:
> [snip]
> type functions are one way to make this happen.
> However changes to the language are hard justify therefore I am currently revisiting,
> approaches to infer type-function-like behavior and transform them behind the scenes.
> (Which is a HUGE pain, because you have to transform recursion into loops, which is a hard problem in itself, AND the user probably would rather have written a loop, but was forced by the language to use recursion. )
> [snip]

I was just thinking about this again in light of Manu's recent post [1] on the bonus thread. Manu specifically mentions types not working well in static contexts like types and aliases.

It occurs to me that there may be a connection between what Manu said and the issue that DIP 1023 [2] attempted to resolve. For instance, consider the DIP example
alias PackedUpperTriangularMatrix(T) = Slice!(StairsIterator!(T*, "-"));
What if instead you have a function that takes a type and returns an alias to another type? Ignoring any issues with the syntax, it might look something like this
alias PackedUpperTriangularMatrix(T)() {
    return alias Slice!(StairsIterator!(T*, "-"));
}
and could be used like
auto foo(T)(PackedUpperTriangularMatrix!T m) { }
(which is the same as in the DIP).

At the end of the day, you would still need to ensure the compiler would actually resolve those types before the function is called. So I imagine that just adding the support to be able to do the first bit does not imply the second bit would work. However, the issue with the solution presented in DIP 1023 was that it was only designed to work with the short alias syntax and not the full template alias syntax, which may not have been possible and could have led to a special casing. This is a simple rule: resolve the type/alias functions first.

I know on other threads you have talked about how much work it would be to go further with type functions and you would need Walter's blessing and help. However, I think that if it means that we could get an alternative resolution to the issues brought up by DIP 1023, then I would be all on board (and willing to contribute to support the work).


[1] https://forum.dlang.org/post/mailman.3585.1591274099.31109.digitalmars-d@puremagic.com
[2] https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1023.md

On Thursday, 4 June 2020 at 11:13:12 UTC, Jacob Carlborg wrote:
> On Wednesday, 3 June 2020 at 21:01:48 UTC, Steven Schveighoffer wrote:
>> But the question above is still unanswered -- writeln receives a string as an immutable(char)[], and doesn't know that it's from a literal.
>
> Perhaps add an overload that takes `const(char)*`?

That overload would be unsafe:

const c = 'c';
writeln(&c);
writeln(&"s".idup[0]);

On Thursday, 4 June 2020 at 09:10:06 UTC, Jacob Carlborg wrote:
> On Wednesday, 3 June 2020 at 14:58:59 UTC, Stanislav Blinov wrote:
>
>> A good `writeln` would not call into C  at all.
>
> What would it do then? Call syscalls in the kernel directly? That's more or less only supported on Linux. It's definitely not supported on macOS. You can do it, but it's not supported and make break at any time. Go used to do that, something broke for them and now they're going through the C wrappers.

Going through the system's library to *make syscalls*, yes. Obviously I'm presenting an idealized case. If you can't sustain direct interop with the OS to maintain compatibility, then yes, while unfortunate, you'd use what you have to. But that is a far cry from unconditionally routing your stdout through FILE*.
The situation with Mac only highlights how infectuous C actually is. And Linux is only slightly better, to be honest.

On Tuesday, 2 June 2020 at 06:47:54 UTC, Walter Bright wrote:
> Many people are trying to figure out what templates are blowing up their compile. This should help:
>
> https://github.com/dlang/dmd/pull/11208

What if DMD had an opt-in option to gather and send detailed profiling data on compiles automatically? (If someone wanted to they could use Differential Privacy to randomize the numbers while preserving the overall informational content.)

On 6/3/20 4:02 PM, Walter Bright wrote:
> On 6/3/2020 7:04 AM, Adam D. Ruppe wrote:
>> tbh I think this case looks worse than it is.
> 
> Not if you look at the code generated by:
> 
>    import std.stdio;
> 
>    void test()
>    {
>      writeln("hello");
>    }
> 
> It's embarrassing.

Here it is: https://godbolt.org/z/LjUtc4

I was surprised.

It would be great if someone took a look at that.

On Friday, 5 June 2020 at 20:10:30 UTC, Andrei Alexandrescu wrote:
> On 6/3/20 4:02 PM, Walter Bright wrote:
>> On 6/3/2020 7:04 AM, Adam D. Ruppe wrote:
>>> tbh I think this case looks worse than it is.
>> 
>> Not if you look at the code generated by:
>> 
>>    import std.stdio;
>> 
>>    void test()
>>    {
>>      writeln("hello");
>>    }
>> 
>> It's embarrassing.
>
> Here it is: https://godbolt.org/z/LjUtc4
>
> I was surprised.
>
> It would be great if someone took a look at that.

What surprised you?

On 6/5/20 4:12 PM, Stefan Koch wrote:
> On Friday, 5 June 2020 at 20:10:30 UTC, Andrei Alexandrescu wrote:
>> On 6/3/20 4:02 PM, Walter Bright wrote:
>>> On 6/3/2020 7:04 AM, Adam D. Ruppe wrote:
>>>> tbh I think this case looks worse than it is.
>>>
>>> Not if you look at the code generated by:
>>>
>>>    import std.stdio;
>>>
>>>    void test()
>>>    {
>>>      writeln("hello");
>>>    }
>>>
>>> It's embarrassing.
>>
>> Here it is: https://godbolt.org/z/LjUtc4
>>
>> I was surprised.
>>
>> It would be great if someone took a look at that.
> 
> What surprised you?

Code, code everywhere...

On Friday, 5 June 2020 at 20:18:01 UTC, Andrei Alexandrescu wrote:
> On 6/5/20 4:12 PM, Stefan Koch wrote:
>> On Friday, 5 June 2020 at 20:10:30 UTC, Andrei Alexandrescu wrote:
>>> On 6/3/20 4:02 PM, Walter Bright wrote:
>>>> On 6/3/2020 7:04 AM, Adam D. Ruppe wrote:
>>>>> tbh I think this case looks worse than it is.
>>>>
>>>> Not if you look at the code generated by:
>>>>
>>>>    import std.stdio;
>>>>
>>>>    void test()
>>>>    {
>>>>      writeln("hello");
>>>>    }
>>>>
>>>> It's embarrassing.
>>>
>>> Here it is: https://godbolt.org/z/LjUtc4
>>>
>>> I was surprised.
>>>
>>> It would be great if someone took a look at that.
>> 
>> What surprised you?
>
> Code, code everywhere...

To me it looks like an accurate translation of the source code.