Menu
Search

Forums

Forum Index

November 29, 2022
Gravatar of zjhPosted by zjh
in reply to Paul Backus		Reply
zjh
Gravatar of zjh
Posted in reply to Paul Backus


Reply

On Tuesday, 29 November 2022 at 03:37:39 UTC, Paul Backus wrote:

>

because in the general case only the user has the knowledge necessary to establish the correspondence between a templated type's structure (e.g., "the head-mutable version of const(Foo!T)") and its name (e.g., Foo!(const(T))).

The problem is, that solution has been declared categorically off the table, so we are stuck going in circles debating the merits and shortcoming of various half-measures.

There are solutions, why not to apply it?
D should not become a religion.

November 29, 2022
Gravatar of Paul BackusPosted by Paul Backus
in reply to zjh		Reply
Paul Backus
Gravatar of Paul Backus
Posted in reply to zjh


Reply

On Tuesday, 29 November 2022 at 04:05:46 UTC, zjh wrote:

>

On Tuesday, 29 November 2022 at 03:37:39 UTC, Paul Backus wrote:

>

because in the general case only the user has the knowledge necessary to establish the correspondence between a templated type's structure (e.g., "the head-mutable version of const(Foo!T)") and its name (e.g., Foo!(const(T))).

The problem is, that solution has been declared categorically off the table, so we are stuck going in circles debating the merits and shortcoming of various half-measures.

There are solutions, why not to apply it?
D should not become a religion.

Walter Bright is strongly opposed to adding user-defined implicit conversions to D. You can search the forum for his posts on the subject; here is one example:

https://forum.dlang.org/post/rs9k19$1982$1@digitalmars.com

November 29, 2022
Gravatar of Steven SchveighofferPosted by Steven Schveighoffer
in reply to Paul Backus		Reply
Steven Schveighoffer
Gravatar of Steven Schveighoffer
Posted in reply to Paul Backus


Reply

On 11/28/22 10:37 PM, Paul Backus wrote:

>

On Tuesday, 29 November 2022 at 03:03:37 UTC, Steven Schveighoffer wrote:

>

The problem is that there's no syntax to "tail-modify" a type other than a pointer or an array. This is the biggest problem with properly using const on ranges (it doesn't prevent using const containers, or prevent ranges to const data, it just prevents taking a range to a mutable container and iterating it via a const parameter).

I think I've been bringing this problem up for 10 years. It would be a huge win to get it solved.

The thing is, we pretty much know what the solution is. In the general case, solving this requires user-defined implicit conversions, because in the general case only the user has the knowledge necessary to establish the correspondence between a templated type's structure (e.g., "the head-mutable version of const(Foo!T)") and its name (e.g., Foo!(const(T))).

This is not how I would solve it. I would solve it in the general case, with a new syntax.

-Steve

November 28, 2022
Gravatar of Walter BrightPosted by Walter Bright
in reply to deadalnix		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to deadalnix


Reply
On 11/28/2022 6:42 PM, deadalnix wrote:
> On Tuesday, 29 November 2022 at 01:27:32 UTC, Walter Bright wrote:
>> It would be nice if you enumerated those fundamental problems. I don't know what they are.
> 
> I have done so numerous times. Every single god damn time you answer the same thing.

I don't doubt you. The trouble is, the n.g. is ephemeral. Once it scrolls away, it's forgotten.

A more permanent document is needed, one you can just link to instead of repeating yourself, which I agree must be annoying for you. For example, I've proposed an improvement to C for years, and wrote an article about it which I just link to rather than having to explain it again endlessly.

https://www.digitalmars.com/articles/C-biggest-mistake.html

Adding Enhancement Requests to bugzilla also can serve this purpose.


> IT IS NOT POSSIBLE TO WRITE A COLLECTION IN D THAT BEHAVE PROPERLY AS PER THE TYPE SYSTEM'S RULES.
> 
> Is that big enough? vector? Set? Map? Does any of it ring a bell? Even range code completely shits the best as long as you throw a const in there.
> 
> Type qualifier do not turtle down (Vector!int and Vector!const(int) are completely unrelated constructs), the top level qualifier need to be able to pop when things are passe by value, etc...

Top level qualifiers can be removed with:

    cast()expression
November 29, 2022
Gravatar of zjhPosted by zjh
in reply to Paul Backus		Reply
zjh
Gravatar of zjh
Posted in reply to Paul Backus


Reply

On Tuesday, 29 November 2022 at 04:12:14 UTC, Paul Backus wrote:

>

Walter Bright is strongly opposed to adding user-defined implicit conversions to D. You can search the forum for his posts on the subject; here is one example:

https://forum.dlang.org/post/rs9k19$1982$1@digitalmars.com

In C++, I have never used implicit conversion. I just add an explicit.
This seems to be a problem of "const" limitation. I think that, like user defined implicit conversion, you can add an attribute to machine check. In this way, users are only allowed to add an "implicit conversion" of a "specific" attribute, which may be a real implicit conversion, indicating that the user knows what he is doing.

November 28, 2022
Gravatar of Walter BrightPosted by Walter Bright
in reply to Adam D Ruppe		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Adam D Ruppe


Reply
On 11/28/2022 6:53 PM, Adam D Ruppe wrote:
> Curious, what did you find lacking in std.sumtype?
> 
> Same question to Walter.

It's addressed in the draft DIP I just posted.

https://github.com/WalterBright/DIPs/blob/sumtypes/DIPs/1NNN-(wgb).md

I did email std.sumtype's author, Paul Backus, for his observations but have not heard back yet.
November 28, 2022
Gravatar of Walter BrightPosted by Walter Bright
in reply to rikki cattermole		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to rikki cattermole


Reply
On 11/28/2022 6:46 PM, rikki cattermole wrote:
> Seriously, 2-3 days an actual dmd compiler dev could probably get ModuleInfo exportation on Windows working correctly and we could get shared library support in D starting to actually be decent.
> 
> Just that one fix would mean we could close FOUR issues extremely easily! And add a whole new realm of possibilities for D.

When posting things like this, links to the bugzilla entries are most appreciated.
November 28, 2022
Gravatar of Walter BrightPosted by Walter Bright
in reply to zjh		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to zjh


Reply
On 11/28/2022 6:37 PM, zjh wrote:
> Can a `dip` be similar to a `plug-in`? As long as the `dip` author implements the corresponding `interface`, there will be a command line `preview` for it automatically?


I think you meant "fork" :-/
November 29, 2022
Gravatar of zjhPosted by zjh
in reply to Walter Bright		Reply
zjh
Gravatar of zjh
Posted in reply to Walter Bright


Reply

On Tuesday, 29 November 2022 at 07:29:21 UTC, Walter Bright wrote:

>

On 11/28/2022 6:37 PM, zjh wrote:

 >

I think you meant "fork" :-/

I just wonder if it is possible to use plug-ins like vim to expand D.
Although the official does not agree with this behavior, but because the code is released along with the official installation, as long as you turn on a switch, you will gain the ability,like class level private.

November 29, 2022
Gravatar of zjhPosted by zjh
in reply to zjh		Reply
zjh
Gravatar of zjh
Posted in reply to zjh


Reply

On Tuesday, 29 November 2022 at 07:44:14 UTC, zjh wrote:

>

I just wonder if it is possible to use plug-ins like vim to expand D.

Developing D like vim and vim's plugin.

« First   ‹ Prev
1 2 3 4 5 6 7 8 9
Next ›   Last »