Re: DIP88 Named Parameters, Status?
On Sunday, October 01, 2017 01:54:24 Jonathan Marler via Digitalmars-d wrote: > Hoping that someone will chime in and answer the original > question. It's likely that only Walter or Andrei can answer it. > > Is it a waste of time for me to put effort into renewing this > DIP? Is it dead on arrival or is there a chance it could be > accepted? Literally, only Walter and Andrei could answer that, because they're the only ones making the decision. Based on what they've said in the past, I would not expect it to be accepted, but it's up to them, and the most that any of the rest of us can do is speculate based on what Walter and Andrei have stated in the past. At bare minimum, I can guarantee that you would have to come up with a very compelling argument as to why a library solution really doesn't cut it, because their answer is almost always no when a library solution can solve the problem - and there are plenty of cases where someone has tried to argue that something should be done in the language because it's less ugly that way, and that rarely seems to get anyone very far. In any case, historically around here, folks asking whether it's worth their time to do something before they do it really don't get a yes or no. The only way to know for sure is to do it. - Jonathan M Davis
Re: DIP88 Named Parameters, Status?
On Saturday, 30 September 2017 at 22:37:31 UTC, Jonathan M Davis wrote: On Saturday, September 30, 2017 16:57:09 solidstate1991 via Digitalmars-d wrote: On Saturday, 30 September 2017 at 16:22:37 UTC, Jonathan M Davis wrote: > [...] What about DIP45, or making export an attribute? That would help the language to go mainstream. As I said, any DIPs on the wiki which have not already been accepted are effectively dead, because the wiki is no longer part of the official DIP process (not that there was much of a process before, which was part of the problem). Whether any of the DIPs on the wiki are a good idea or not is irrelevant. Any DIP that's going to be accepted needs to go through the current DIP process: https://github.com/dlang/DIPs No DIPs are going to magically move from the wiki to github. _Someone_ (be it the original DIP author or someone else) is going to have to take the time and make the effort to do everything that's required as part of the current DIP process, or the DIP will never go anywhere. - Jonathan M Davis Hoping that someone will chime in and answer the original question. It's likely that only Walter or Andrei can answer it. Is it a waste of time for me to put effort into renewing this DIP? Is it dead on arrival or is there a chance it could be accepted?
Re: DIP88 Named Parameters, Status?
On Saturday, 30 September 2017 at 16:57:09 UTC, solidstate1991 wrote: On Saturday, 30 September 2017 at 16:22:37 UTC, Jonathan M Davis wrote: Effectively, all DIPs from that wiki that have not already been accepted are dead, regardless of whether they stand any chance of acceptance. For any DIP to be accepted, it will have to go through the new DIP process, which essentially means creating a new DIP. As for named parameters specifically, I'd be very surprised to see them added to the language. From what I recall, Walter wasn't particularly fond of the idea, and since it _is_ possible to implement them with a library solution, it's exactly the sort of thing that Andrei is likely to veto. At this point, in general, if something can be done in the language as it stands, it's not likely for it to be accepted as a DIP. Now, that's dealt with on a case by case basis, so I can't say for certain that a DIP for named parameters would be rejected, but I would expect it to be. - Jonathan M Davis What about DIP45, or making export an attribute? That would help the language to go mainstream. I was going to do this as part of DIP1012 but Martin Nowak advised me that I should remove it because DIP45 was still being worked on by Benjamin Thaut and that it had some advantages over doing what C/C++ does. So I removed it from DIP1012.
Re: DMD 2.076.0 fails to build a project with dlangui as dependency
On Saturday, September 30, 2017 17:04:45 solidstate1991 via Digitalmars-d wrote: > When I try to build a Hello World app for dlangui under VS2017, I > get this error: > > -- Build started: Project: dlangidefirstrun, Configuration: > Debug Win32 -- > Building Win32\Debug\dlanguifirstrun.exe... > > object.Error@(0): Access Violation > > 0x005BEDEE > 0x005D7FD6 > 0x005A38D0 > 0x005B3676 > 0x0053479E > 0x005ACE2F > 0x005AF442 > 0x00579BA6 > 0x005A77F4 > 0x004EFDDB > 0x004ECE29 > 0x7755F756 in RtlReAllocateHeap > 0x7755F673 in RtlReAllocateHeap > 0x005D7141 > Building Win32\Debug\dlanguifirstrun.exe failed! > > I can build the app with dub with no problem, however I couldn't > find a way to force noGL, and the PC I currently have to use have > poor graphics acceleration support, so the application crashes > immediately, and I have no way to trace back the source of the > issue without mago. I use VS2017 as I couldn't find VS2015 > anymore. Please post questions looking for help in D.Learn, not in the main D newsgroup/forum/mailing list. That's what D.Learn is for. - Jonathan M Davis
Re: DIP88 Named Parameters, Status?
On Saturday, September 30, 2017 16:57:09 solidstate1991 via Digitalmars-d wrote: > On Saturday, 30 September 2017 at 16:22:37 UTC, Jonathan M Davis > > wrote: > > Effectively, all DIPs from that wiki that have not already been > > accepted are dead, regardless of whether they stand any chance > > of acceptance. For any DIP to be accepted, it will have to go > > through the new DIP process, which essentially means creating a > > new DIP. > > > > As for named parameters specifically, I'd be very surprised to > > see them added to the language. From what I recall, Walter > > wasn't particularly fond of the idea, and since it _is_ > > possible to implement them with a library solution, it's > > exactly the sort of thing that Andrei is likely to veto. At > > this point, in general, if something can be done in the > > language as it stands, it's not likely for it to be accepted as > > a DIP. Now, that's dealt with on a case by case basis, so I > > can't say for certain that a DIP for named parameters would be > > rejected, but I would expect it to be. > > > > - Jonathan M Davis > > What about DIP45, or making export an attribute? That would help > the language to go mainstream. As I said, any DIPs on the wiki which have not already been accepted are effectively dead, because the wiki is no longer part of the official DIP process (not that there was much of a process before, which was part of the problem). Whether any of the DIPs on the wiki are a good idea or not is irrelevant. Any DIP that's going to be accepted needs to go through the current DIP process: https://github.com/dlang/DIPs No DIPs are going to magically move from the wiki to github. _Someone_ (be it the original DIP author or someone else) is going to have to take the time and make the effort to do everything that's required as part of the current DIP process, or the DIP will never go anywhere. - Jonathan M Davis
Re: Should we add `a * b` for vectors?
On 9/28/2017 7:42 AM, Wyatt wrote: Any sufficiently advanced bug is indistinguishable from a feature! ;) D has other ways of doing what ADL does, so I am curious for an example from Manu about why it doesn't work.
Re: Should we add `a * b` for vectors?
On 9/29/2017 7:17 PM, Manu wrote: Whether you like it or not, the lack of ADL will make the idea of operator overloading a disaster. Please present an example.
Re: I need runtime reflection
On Friday, 29 September 2017 at 16:40:38 UTC, Gheorghe Gabriel wrote: [...] Still work to do, but usable. https://github.com/nicolasjinchereau/d-reflection
Re: Alternatives to pointers?
On Saturday, 30 September 2017 at 08:27:26 UTC, Timon Gehr wrote:
On 29.09.2017 03:51, Jerry wrote:
I miss ref variables, for the simple fact that using the
square brackets with a ref variable doesn't access the
pointer. Don't know how many times I've accidentially used a
pointer as an array. Not very easy to catch especially if the
object has pointers to other objects of the same type.
Possibly adding something like this, if ref variables are off
the table?
@noarray int* value;
value[x] = 10; // compile error, pointer is not an array.
void main()@safe{
int x;
int* value;
value[x]=10;
}
Error: safe function 'D main' cannot index pointer 'value'
Need it in unsafe/trusted code though.
Re: Alternatives to pointers?
On Saturday, 30 September 2017 at 04:15:52 UTC, bitwise wrote:
On Friday, 29 September 2017 at 01:51:36 UTC, Jerry wrote:
[...]
Maybe this?
ref auto at(T : U[], U)(T arr, size_t index) {
return arr[index];
}
int main(string[] argv)
{
int* a = new int(1);
int[] b = [1];
int[1] c = [1];
a.at(0); // won't compile
b.at(0);
c.at(0);
reutnr 0;
}
That is interesting, it would mean not using "[]" or "[..]",
which would kind of suck.
DMD 2.076.0 fails to build a project with dlangui as dependency
When I try to build a Hello World app for dlangui under VS2017, I get this error: -- Build started: Project: dlangidefirstrun, Configuration: Debug Win32 -- Building Win32\Debug\dlanguifirstrun.exe... object.Error@(0): Access Violation 0x005BEDEE 0x005D7FD6 0x005A38D0 0x005B3676 0x0053479E 0x005ACE2F 0x005AF442 0x00579BA6 0x005A77F4 0x004EFDDB 0x004ECE29 0x7755F756 in RtlReAllocateHeap 0x7755F673 in RtlReAllocateHeap 0x005D7141 Building Win32\Debug\dlanguifirstrun.exe failed! I can build the app with dub with no problem, however I couldn't find a way to force noGL, and the PC I currently have to use have poor graphics acceleration support, so the application crashes immediately, and I have no way to trace back the source of the issue without mago. I use VS2017 as I couldn't find VS2015 anymore.
Re: DIP88 Named Parameters, Status?
On Saturday, 30 September 2017 at 16:22:37 UTC, Jonathan M Davis wrote: Effectively, all DIPs from that wiki that have not already been accepted are dead, regardless of whether they stand any chance of acceptance. For any DIP to be accepted, it will have to go through the new DIP process, which essentially means creating a new DIP. As for named parameters specifically, I'd be very surprised to see them added to the language. From what I recall, Walter wasn't particularly fond of the idea, and since it _is_ possible to implement them with a library solution, it's exactly the sort of thing that Andrei is likely to veto. At this point, in general, if something can be done in the language as it stands, it's not likely for it to be accepted as a DIP. Now, that's dealt with on a case by case basis, so I can't say for certain that a DIP for named parameters would be rejected, but I would expect it to be. - Jonathan M Davis What about DIP45, or making export an attribute? That would help the language to go mainstream.
Re: DIP88 Named Parameters, Status?
On Saturday, September 30, 2017 16:10:44 Jonathan Marler via Digitalmars-d wrote: > https://wiki.dlang.org/DIP88 > > I'd like to see DIP88 (Named Parameters) revived. Was this > proposal rejected or is it just stale and needs a refresh? Named > parameters can be implemented in a library, however, in my > opinion they are useful enough to warrant a clean syntax with > language support. I'd be willing to refresh the DIP so long as I > know the idea has not already been rejected. Effectively, all DIPs from that wiki that have not already been accepted are dead, regardless of whether they stand any chance of acceptance. For any DIP to be accepted, it will have to go through the new DIP process, which essentially means creating a new DIP. As for named parameters specifically, I'd be very surprised to see them added to the language. From what I recall, Walter wasn't particularly fond of the idea, and since it _is_ possible to implement them with a library solution, it's exactly the sort of thing that Andrei is likely to veto. At this point, in general, if something can be done in the language as it stands, it's not likely for it to be accepted as a DIP. Now, that's dealt with on a case by case basis, so I can't say for certain that a DIP for named parameters would be rejected, but I would expect it to be. - Jonathan M Davis
DIP88 Named Parameters, Status?
https://wiki.dlang.org/DIP88 I'd like to see DIP88 (Named Parameters) revived. Was this proposal rejected or is it just stale and needs a refresh? Named parameters can be implemented in a library, however, in my opinion they are useful enough to warrant a clean syntax with language support. I'd be willing to refresh the DIP so long as I know the idea has not already been rejected.
Re: D's SwitchStatement accepts statements with ridiculous semantics
On Friday, 29 September 2017 at 09:12:54 UTC, Don Clugston wrote: Or it may have just been an accident. But regardless of the original motivation, it allows some truly dreadful semantics. Can we disallow this silliness please? There are two big family of switches. C-like and Pascal like. In Pascal you can only have cases in the switch. See https://en.wikipedia.org/wiki/Switch_statement#Semantics The C form doesn't prevent you to be stricter but it's all about self-discipline since the compiler will allow everything in there.
Re: D's SwitchStatement accepts statements with ridiculous semantics
30.09.2017 05:35, sarn пишет:
For anyone who's wondering, it works because switch is just a computed
goto. The code's equivalent to this:
import std.stdio;
void main()
{
int i = 0;
// switch(i)
if (i == 7)
{
goto case_7;
}
else
{
goto case_default;
}
// for loop initialiser
i = 8;
// for loop test
while (i < 10)
{
case_7:
writeln(i);
return;
case_default:
// for loop update
++i;
}
}
Thanks for clarification!
Re: Alternatives to pointers?
On 29.09.2017 03:51, Jerry wrote:
I miss ref variables, for the simple fact that using the square brackets
with a ref variable doesn't access the pointer. Don't know how many
times I've accidentially used a pointer as an array. Not very easy to
catch especially if the object has pointers to other objects of the same
type. Possibly adding something like this, if ref variables are off the
table?
@noarray int* value;
value[x] = 10; // compile error, pointer is not an array.
void main()@safe{
int x;
int* value;
value[x]=10;
}
Error: safe function 'D main' cannot index pointer 'value'
Re: D's SwitchStatement accepts statements with ridiculous semantics
On 2017-09-29 21:56, Timon Gehr wrote: Well, I have used the switch(...) with(...) idiom you mentioned in the original post a few times, and I'm quite confident you'd meet some opposition if you were to break it. I've used that as well, but the other way around. I put the switch statement inside the with statement. -- /Jacob Carlborg
