Re: If you're on an Windows XP or Vista box and live in the U.S...
On 3/24/2011 3:59 PM, Nick Sabalausky wrote: Since MS no longer offers legitimate copies of XP Windows 7 Professional (and above) comes with a full license for XP in a virtual machine. That's how I got my results above. Reference: http://www.microsoft.com/windows/virtual-pc/default.aspx
Re: "body" keyword is unnecessary
On 3/24/2011 12:55 PM, Steven Schveighoffer wrote: I wouldn't mind it becoming a contextual keyword (like C#'s get and set inside properties). This is exactly what it should be.
Re: "body" keyword is unnecessary
On 3/24/2011 12:55 PM, Steven Schveighoffer wrote: But I don't know that it's so terrible to have it as a keyword. Clearly there was a "free keyword love" period in D's past, but I think it takes a lot more than just "we could technically do this without a keyword" to remove it from the language. For one, it would break tons of existing code. As I mentioned above, "body" can be removed as a keyword without removing it from the syntax. There's no chance of of confusion with any other type of symbol.
Re: If you're on an Windows XP or Vista box and live in the U.S...
California, Windows XP via Virtual PC: 1999-Mar-01 00:00:00 1999-Mar-08 00:00:00 1999-Mar-14 00:00:00 1999-Mar-14 01:00:00 1999-Mar-14 01:00:00 1999-Mar-14 02:00:00 1999-Mar-14 23:00:00 1999-Mar-21 23:00:00 1999-Mar-28 23:00:00 1999-Mar-31 23:00:00 1999-Apr-02 23:00:00 1999-Apr-04 00:00:00 1999-Apr-04 01:00:00 1999-Apr-04 03:00:00 1999-Apr-05 00:00:00 For comparison, here's Windows 7: 1999-Mar-01 00:00:00 1999-Mar-08 00:00:00 1999-Mar-14 00:00:00 1999-Mar-14 01:00:00 1999-Mar-14 01:00:00 1999-Mar-14 02:00:00 1999-Mar-14 23:00:00 1999-Mar-21 23:00:00 1999-Mar-28 23:00:00 1999-Mar-31 23:00:00 1999-Apr-02 23:00:00 1999-Apr-04 00:00:00 1999-Apr-04 01:00:00 1999-Apr-04 03:00:00 1999-Apr-05 00:00:00
Re: "body" keyword is unnecessary
Interestingly, you don't even have to remove "body" from the syntax to remove it as a keyword, as it's only used in this context (that I know of), where no other symbols make sense.
Re: Pretty please: Named arguments
On 3/23/2011 9:12 AM, Bruno Medeiros wrote: Now that is an argument. Although I still don't agree: it really shouldn't take that long to setup an IDE (if Netbeans and/or its PHP plugin are crappy, don't use that to blame all IDEs :P ). But in any case this is kinda besides the point, because setting up an IDE is a one-time affair (reviewing code is many-times). There is far more cost involved in using an IDE than the setup time. A typical IDE will: - Consume a relatively large chunk of space. Visual Studio on my system takes up 1.9 GB, with one of the platform SDKs taking up an additional 565 MB. XCode on my other system eats up a whopping 9.7 GB (!) with the iOS SDK (the download for XCode 4 with iOS SDK 4.3 is 4.2 GB for the .dmg file). Eclipse puts them both to shame at 268 MB for Eclipse Classic, with the JDK adding 179 MB on top of that. (I only use Eclipse for Android development, so I haven't installed anything beyond the base classic package.) For D development, I use Notepad++, which is just an editor -- 11.8 MB (plus 105 MB for dmd and associated tools). - Hijack file extensions. I have several versions of Visual Studio installed that all cooperate very nicely with each other, but if I were to install Eclipse for C/C++ development, I'd have to remember to tell it not to take over handling for .c/.cpp files. This isn't such a big deal if the IDE only handles one or two languages, but if it's a multi-language IDE, then there may be a list of twenty or more file types to scroll through, assuming that the installer is even nice enough to let you choose. - Have its own shortcuts, features, and quirks. In Visual Studio, I can hit tab to confirm intellisense suggestions. If I do the same thing in Eclipse, then I end up shifting focus over to the documentation popup window, which is just maddeningly stupid. XCode doesn't give me a list; it just inserts its suggestion inline, and then I have to either hit escape or keep typing if I want something else entirely. (XCode's suggestions also seem to be highly non-deterministic in nature; I think their algorithm would make for a great prng.) Build in Visual Studio is F7. In Eclipse, it's ctrl-b, which at least matches XCode's cmd-b. This can be mitigated in most cases by changing key bindings, but now you're looking at either a short list of commands that can be changed (which might not include the command you're looking for), or a very, *very* long list with hundreds of commands that you have to wade through. What's more, you have to figure out what name the IDE gives to the feature you're looking for, and it may not always be clear. Eclipse provides a search bar to make it easier; good thing, too, because typing "content assist" into that bar gives me back *21 different entries*! - Have its own unique, non-portable project format. Some IDEs can work with makefiles, but even most of those don't actually use a makefile as its preferred project format. This means that if you're looking at different projects from n different people/groups, you may need O(log(n)) different IDEs just to be able to open up their project. On the flip side, if you're the author of a project and you want people to be able to use their favorite IDE, then you have to provide several different sets of project configuration files. At least with makefiles, other people can build your project from the command-line without installing your favorite IDE. (Same goes for Visual Studio project files, actually; you can build those from the command line with MSBuild without having to install Visual Studio.) Lastly, at this point, D just doesn't have much in the line of support from major IDEs. There are neat projects like Descent and VisualD, but that's hardly the breadth or scope of support that you'd get with an established, highly-visible language. IDEs are simply not part of the language specification, and the language shouldn't be designed under the assumption that everyone's going to use an IDE, especially if you're thinking about a particular feature which many IDEs might not even have. Don't get me wrong -- I love IDEs. They can be very helpful, especially when it comes to dependency tracking and assisted editing. Right now, I use Notepad++ for D because I don't feel that the existing alternatives really offer that much useful functionality beyond what that editor provides. I'm working on some MSBuild tasks to make the process easier (yes, I develop primarily in Windows), and the IDE story will get better, but these things take a lot of time to fully materialize.
Re: Different types with auto
On 3/18/2011 12:59 PM, bearophile wrote: http://d.puremagic.com/issues/show_bug.cgi?id=2656 Thank goodness that's under discussion.
Re: Why can't structs be derived from?
On 3/18/2011 7:09 AM, Nick Sabalausky wrote: "typedef b a;" (or "typedef a = b;") Regarding syntax, maybe: typedef A : int; typedef B : int; ...with semantics as follows: A a = 5;// ok B b = a;// error int i = a; // ok a = i; // error a = cast(A)i; // ok b = cast(B)a; // error b = cast(B)cast(int)i; // ok Possibly instead of 'typedef' we should be using a non-C keyword. Heck, even 'type' works: type A : int; ...and is more consistent with existing type declarations (we use 'class', 'struct', and 'enum', not 'classdef', 'structdef', and 'enumdef'). Not sure if typedef should work with aggregates; that might just get too confusing. Bleh. Now I'm /really/ off-topic...
Re: Why can't structs be derived from?
On 3/17/2011 2:36 PM, Andrei Alexandrescu wrote: I'm with y'all too. Even Walter needs to stop and think for a second. We're considering enabling alias a = b; as an equivalent for alias b a; Along similar lines (hoping this isn't too far off-topic), what's the current plan for typedef? I'm aware that it's deprecated (and for good reason), but some of my reading suggests that there's a successor on the horizon.
Re: Why can't structs be derived from?
On 3/17/2011 2:36 PM, Andrei Alexandrescu wrote: I'm with y'all too. Even Walter needs to stop and think for a second. We're considering enabling alias a = b; as an equivalent for alias b a; Please yes. I'd even be in favor of deprecating the old usage, even though every project under the sun (to within experimental error) currently uses it.
Re: std.xml: Why is it so slow? Is there anything else wrong with it?
Do we want to take a look at libxml, or are there legal issues with that?
Re: Proposal for std.path replacement
On 3/7/2011 7:07 AM, Adam D. Ruppe wrote: A better solution would be to store it in the filename. Might want more detail than one byte could allow too, so perhaps allowing three or four bytes would be a good answer. With the type in the filename, you can determine it easily from a directory listing without needing to open every individual file. This would make a big difference in listing speed on a slow filesystem and by using the name, it is compatible with all systems too. Along those same lines: http://blogs.msdn.com/b/oldnewthing/archive/2009/04/15/9549682.aspx
Re: Proposal for std.path replacement
On 3/7/2011 2:30 PM, Nick Sabalausky wrote:
--
{almost everything else}
--
Implies:
1. The ANSI/ASCII APIs should just simply *never* be used.
This right here is something that I think needs to be drilled into every
potential Windows programmer out there. The underlying file system
usually encodes file names in Unicode, which provides great flexibility.
The ANSI versions of Windows API functions *cannot* handle that. It
is therefore impossible to guarantee that you can handle a valid Windows
file path using the ANSI version of a function.
ANSI versions exist /for backwards compatibility only/. New
functionality is often introduced without even providing an ANSI version
of the function. Just simply do not use ANSI functions.
Re: Proposal for std.path replacement
On 3/6/2011 4:11 AM, Lars T. Kyllingstad wrote: Interestingly, it seems drive names are actually restricted to one letter. See the last paragraph of this section: http://en.wikipedia.org/wiki/Drive_letter#Common_assignments -Lars Correct. However, the rules change for UNC paths: http://msdn.microsoft.com/en-us/library/aa365247%28v=VS.85%29.aspx
Re: Proposal for std.path replacement
dirSeparator -- I'd actually prefer pathSeparator, but that's not on the list. currentDirSymbol baseName dirName driveName extension stripExtension Abbrvs impr rdblty.
Re: Proposal for std.path replacement
On 3/3/2011 7:23 PM, Graham St Jack wrote: Ok, I don't mind supporting wchar and dchar in addition to char, especially if Windows insists on using them. My main issue here is with the constness of the parameters. I think the correct parameter to pass is const C[]. This has the advantages of: * Accepting both mutable and immutable data. * Declares that the function won't mutate the data. * Declares that the function doesn't expect the data to be immutable. Agreed; I think I might modify that slightly to "in" instead of "const", but it means the exact same thing. Once upon a time "in" meant const scope. Does anyone know what it means now? "in" is a synonym for a non-parenthesized const.
Re: Proposal for std.path replacement
On 3/3/2011 10:17 PM, Jonathan M Davis wrote: Once upon a time "in" meant const scope. Does anyone know what it means now? That's still what it means. scope in this context is _not_ deprecated. Oh, hey, I didn't know that. Even better. Thanks!
Re: Proposal for std.path replacement
On 3/3/11 3:30 PM, Graham St Jack wrote: My first instinct would be to use non-templated functions that take const char[]. Please don't ever restrict encodings like that. As much as possible, libraries should seek to be encoding agnostic (though I'm all for const-qualifying parameters). This is one area where I feel the standard library severely lacks at present. As a Windows developer, I prefer to use wchar strings by default and use only the W versions of the Windows API functions, because the A versions severely limit functionality. Only the W versions have full support for Unicode; the A versions are entirely dependent on the current (8-bit) code page. This means no support for UNC paths or paths longer than 260 characters, and also means that international characters commonly end up completely garbled. Good practice in Windows is to consider the A versions deprecated and avoid them like the plague. References: http://msdn.microsoft.com/en-us/library/dd317752%28v=VS.85%29.aspx http://blogs.msdn.com/b/michkap/archive/2006/10/24/867880.aspx http://blogs.msdn.com/b/michkap/archive/2006/08/22/707665.aspx http://blogs.msdn.com/b/michkap/archive/2007/05/07/2464778.aspx When I first started looking at D, I compiled the win32 example on the D web page. I noticed it used MessageBoxA, so I changed that to MessageBoxW. That generated an error, because nobody had bothered to add a MessageBoxW declaration. That was the very last time I used std.c.windows.
Re: Is @property implementable?
On 3/2/2011 9:21 PM, Jonathan M Davis wrote:
Well, it wouldn't be universal then.
Agreed, and really, I don't have a problem with it being universal. I'd
prefer an annotation, but it's not that big a deal. I'm just thinking
of the following situation:
lib1.di:
class Lib1Class
{
...
version (2)
{
void bar();
}
}
lib2.di:
import lib1;
void bar(Lib1Class l1c);
main.d:
import lib1;
import lib2;
void main()
{
Lib1Class foo;
foo.bar();
}
Through no fault of the caller or of lib2, foo.bar() goes from one
completely valid meaning to another when lib1 is versioned. Lib1 and
lib2 could be from different authors, so lib1's author had no idea he'd
just hijacked a function call.
With an annotation, the compiler could at least spit out a warning for
lib2.di. (I would be absolutely opposed to a warning for line 7 of
main; that should be an unambiguous method call in version 2.)
Anyway, I'm just thinking out loud (erm, in text); I'm sure this has all
been debated already.
Re: Is @property implementable?
On 3/2/2011 8:41 PM, Jonathan M Davis wrote: Uniform Function Call Syntax. It means that _any_ type could have functions called on it as if they were member functions of that type. e.g. OK, thanks. This sounds like the sort of thing that should require an annotation in the declaration...
Re: Is @property implementable?
On 3/2/2011 6:36 PM, Jonathan M Davis wrote: Because a property must be a property _of_ something. It's essentially an abstraction of a member variable. It allows you to use a function as if it were a member variable. That's its whole purpose. Very much agreed. I'm not sure I'm familiar with UFCS; can you point me to some documentation/discussion on it?
Re: How fast is D compared to C++?
On 3/2/11 11:40 AM, Trass3r wrote: I just can't imagine why in should be faster than const ref. The use of ref introduces a level of indirection. I suspect the writer was trying to avoid copying array elements -- unnecessary, since vector_t was defined as a dynamic array, where only the bounds are passed. With ref, every access to a vector_t object involves a pointer dereference. Take out the ref, and const should behave identically to in. (It had better -- in and const are synonyms!)
Re: Pretty please: Named arguments
On 3/2/11 8:45 AM, spir wrote: I had never thought at that, but I'm surprised: what prevents Python's "compiler" (say, a semantic phase after parsing) to check number and names of arguments. (Number seems not to be checked before runtime neither.) All required information is in the AST. For named params, Python could translate to position params just like D. This would certainly remove a relevant amount of runtime "speed-down", I guess. (Only type-check of builtin func args must remain at runtime.) Denis What follows is speculation; I'm not a Python programmer, but I am loosely familiar with the language. If I'm completely wrong, I'm sure someone will point it out: A Python "compiler" certainly can (and probably does) check function arguments, but the runtime is still heavily involved in argument passing. The complexity in Python is an artifact of how arguments are delivered at run-time: in a big (dynamically created, of course) dictionary. Essentially, The interpreter matches argument positions with parameter names -- at run time -- and then supplies those name/argument pairs as entries in the dictionary. (This is a logical view of the language, and may not precisely match implementations. For instance, I'd expect that "compiled" .pyc files throw out positional information ahead of time.) Looked at another way, *everything* is passed by name, not position; positional arguments are merely a shorthand notation. This is vastly different from how named arguments would be handled in D. D passes arguments by position -- end of story. Named arguments provide an alternative method of specifying the position of a given argument, which is determined by the compiler long before the linker or the runtime get involved.
Re: Pretty please: Named arguments
On 3/2/2011 1:34 AM, Max Samukha wrote: I am not against named arguments. What I wanted to say is that writef(formatstr: "...", ) does not make the code more readable. Right, agreed. This is one of the "not helpful" cases, where you simply don't use named arguments. I'd expect (and hope for) most function calls to fall into that category. Also, I shudder at the thought that the compiler guys may stop working on the toolchain issues and rush to implement named arguments instead. I'm only just becoming aware of the scope of the toolchain issues, so I'm not really qualified to comment on that. This doesn't have to go to the front of the queue, but it'd be nice to see it scheduled for D2.
Re: std.path.getName(): Screwy by design?
On 3/1/2011 7:32 PM, Walter Bright wrote: I didn't know that. Thanks for the link! No problem.
Re: std.path.getName(): Screwy by design?
On 3/1/11 5:26 PM, Walter Bright wrote: Yeah, one wonders what's wrong with the word "Programs". And why directories had to be renamed "folders". Ah, this one (folders) I actually have a response for. Or, rather, Raymond Chen does: http://blogs.msdn.com/b/oldnewthing/archive/2011/02/16/10129908.aspx Absolutely agreed re: "Programs".
Re: std.path.getName(): Screwy by design?
On 3/1/11 3:40 PM, Daniel Gibson wrote: Or "My Documents", "My Pictures" and whatnot (or is that gone post-XP?) Yes, those are gone. "My Documents" is just "Documents", "My Pictures" is just "Pictures", etc. Windows 7 (sadly) still displays the "My" prefix (Vista doesn't), but the directory names don't have it.
Re: Sci-Fi TV Shows (Was: std.path.getName(): Screwy by design?)
On 3/1/11 2:56 PM, Nick Sabalausky wrote: "Jonathan M Davis" wrote in message No. It's a cat. :) - Jonathan M Davis P.S. At least it is if you've seen B5... OMG, I completely forgot about the whole cat thing in Babylon 5 (I assume you mean Babylon 5). It's been far too long. Actually, I still haven't gotten any further then about halfway through season 4. I really need to finish that sometime. Wait, are you sure that wasn't Andromeda? Definitely Babylon 5. Brilliant show, despite some unfortunate dialogue here and there (of which "being nibbled to death by cats" is *not* an example).
Re: std.path.getName(): Screwy by design?
On 3/1/11 3:27 PM, Walter Bright wrote: I've always hated the Windows "Documents and Settings" subdirectory. Arggh. Always a pain to use on the command line. No kidding. Thank goodness that's gone post-XP. Now if only they'd do the same for Program Files...
Re: Pretty please: Named arguments
On 2/28/11 1:38 PM, Don wrote: 1. It makes parameter names part of the API. I wrote earlier that this would probably be the first time parameter names "leaked" into user code, but I was wrong. Jacob Carlborg has pointed out his library implementation of this feature: http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135 If you look through his implementation, you'll see that it uses the .stringof property to extract parameter names from the function definition. In essence, parameter names are /already/ part of the API, because code can be written that depends on them. And the fact that a library implementation exists specifically to facilitate the use of named arguments implies that code already /has/ been written that depends on parameter names. Like it or not, parameter names are already part of the API. Adding named arguments as a language feature doesn't change that.
Re: Pretty please: Named arguments
On 2/28/11 9:07 PM, Nick Sabalausky wrote: One could argue the code is more likely like this: int x = 1; int y = 2; int width = 3; int height = 4; ... box(x, y, width, height) Right, at which point you're essentially using named arguments anyway, except that here, a) it's not verified by the compiler, b) you've added stack or static variables (perhaps needlessly), and c) you're polluting the local namespace.
Re: Pretty please: Named arguments
On 3/1/11 4:52 AM, Max Samukha wrote: I hate that "explicitness improves code clarity and readability" argument. It may be true in some cases but most of the time explicitness creates unnecessary redundancy that actually impairs readability. Correct. However, named arguments are not a "most of the time" feature. Just look at some Python code, where named arguments have been supported for a very long time; you'll still mostly see people making calls using positional arguments, which is as it should be. Named arguments are there for when they're helpful, and get out of the way when they're not.
Re: Pretty please: Named arguments
On 3/1/11 4:40 AM, Lars T. Kyllingstad wrote: I just think that, at this late point in D2's development, the cost of adding them outweighs the benefits. I mean, have you looked at the spec for D2 lately? It's starting to look like the OOXML spec! I started out a few weeks ago by reading through the entire spec as posted on the digitalmars site. It only took a few days of off-time reading. It's maybe a tenth the size of the C++ spec, if even that. Which is great -- I wouldn't want to needlessly bloat the spec -- but I don't think that argument carries much weight.
Re: Pretty please: Named arguments
On 3/1/11 1:51 AM, Lars T. Kyllingstad wrote:
I think I agree with you and Don here. As for "skipping" default
parameters, I suggest the following syntax:
void foo(int i, bool b = true, real r = 3.14, string s = "")
{ ... }
foo(1, , , "Hello World!");
This is a much smaller language change than named parameters.
-Lars
When reading existing code, can you easily spot the difference between:
foo(1,,, "Hello World!");
and
foo(1 "Hello World!");
?
Unlike named arguments, I'd argue this syntax makes things quite a bit
/less/ readable.
Re: Pretty please: Named arguments
On 2/28/2011 9:24 PM, Nick Sabalausky wrote: std.algorithm has far worse signatures. The main problem I have with the above is that it only solves a barely-existent "problem". Right, exactly. Thinking about it some more, I don't really think the changing parameter name issue really justifies parameter name aliases.
Re: Pretty please: Named arguments
On 2/28/2011 8:43 PM, Andrei Alexandrescu wrote: Don't know about others, but I think this is exactly the point where my "meh" detector goes off. It *might* be worthwhile if it does indeed address Jonathan's concern about library writers not being able to change parameter names. I'm not sold that that's really such a big deal; I expect that parameter name aliases would be so rarely used as to disappear into obscurity. But I could be wrong.
Re: Pretty please: Named arguments
On 2/28/11 5:53 PM, Stewart Gordon wrote: I don't know, but possibly void setColour(int colour alias color); and with a possibility of deprecating old names int find(string haystack deprecated alias s1, string needle deprecated alias s2); I think that could work; I don't mind the verbosity, given that the actual need for a parameter name alias should be exceedingly rare.
Re: Pretty please: Named arguments
On 2/28/11 4:50 PM, Stewart Gordon wrote: But one way around that would be to support parameter aliases, which would also confer a few more benefits. Interesting idea. I think this might solve Jonathan Davis's main complaint; could you give an example of what syntax for that might look like?
Re: Pretty please: Named arguments
On 2/28/11 1:38 PM, Don wrote: spir wrote: On 02/28/2011 07:51 PM, Jonathan M Davis wrote: I'm not entirely against named arguments being in D, however I do think that any functions that actually need them should be refactored anyway. I agree. CreateFont() in the Windows API, I'm looking at you. (For Linux people, that function has about 12 parameters). That's a great example of where named parameters can come in very handy. As a consumer of the API, you do not have the option of refactoring CreateFont(); you have to play the cards you're dealt. Named arguments allow you to annotate in a compiler-verified fashion. Just don't use them! You don't have that option. At least, if you're a library developer, you don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it). You may encounter it, but nothing says you ever have to write it. There is no way to write a function such that callers would have to use named arguments in the function call. (If there were, then I'd agree with you -- that would be bad.) There are a couple of things that I really, really don't like about the names argument idea: 1. It makes parameter names part of the API. Providing no way for the function writer to control whether it is part of the API or not, and especially, doing it retrospectively, strikes me as extremely rude. A valid point. I think I would already consider parameter names to be part of the API, though; generated documentation relies upon them, as do contracts. Admittedly, this would be the first place where they leak directly into caller code. 2. It introduces a different syntax for calling a function. foo(4, 5); foo(x: 4, y: 5); They look different, but they do exactly the same thing. I don't like that redundancy. You're right, it is redundant. So is this: Declaration: void func(int a = 0); Use: func(); // ok func(0);// same as above Are you also against default arguments, then? Especially since, as far as I can tell, the named arguments are just comments (which the compiler can check). Look again at my example from the first post: HRESULT hr = m_Device.Present(hDestWindowOverride: hOverride); In this usage, the named argument allows me to skip over the first two parameters, which receive their default arguments. This seems highly valuable to me. But I still don't see the need for this feature. Aren't people using IDEs where the function signature (with parameter names) pops up when you're entering the function, and when you move the mouse over the function call? The point (in the annotation use case) is less in the writing than in the reading.
Re: Pretty please: Named arguments
On 2/28/11 1:50 PM, Jonathan M Davis wrote: However, I consider them to be a big _problem_, not a feature - _especially_ the ability to rearrange the function arguments. All of a sudden you could have foo(4, 5); foo(x : 4, y : 5); foo(y : 5, X : 4); all making _exactly_ the same function call. That seem _very_ bug-prone and confusing to me. Of those three calls, the highest potential for confusion exists with the first. Admittedly, the third is of uncertain value.
Re: Pretty please: Named arguments
On 2/28/11 11:53 AM, spir wrote: Agreed, and I'm not for adding non-obvious "signs". D is not Perl. Or else use ':=' ? Denis I think we should stick with ':' due to its existing use in static struct initializers.
Re: Pretty please: Named arguments
On 2/28/11 10:51 AM, Jonathan M Davis wrote: I'm not entirely against named arguments being in D, however I do think that any functions that actually need them should be refactored anyway. Are you the author of every function and method you call in your code?
Re: Pretty please: Named arguments
On 2/28/11 4:48 AM, Andrej Mitrovic wrote: I prefer using the equals sign: foo(action = "dofoo", times = 100) This is how Python does it. I went with : because that's what's already used in static struct initializers.
Re: Pretty please: Named arguments
On 2/28/11 5:05 AM, Jacob Carlborg wrote: It's possible to implement this as a library: http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135 Not a complete solution but it works. That has scary syntax; no thanks.
Re: Pretty please: Named arguments
On 2/28/11 4:41 AM, Michel Fortin wrote:
Another problem is what happens if you override a function by using
different parameter names. For instance:
class A {
void func(int foo);
}
class B : A {
void func(int bar);
}
Currently, the above is allowed. Would it now become an error?
Definitely not an error! This feature should not break any existing code.
Method lookup already happens based on the static type of your object
reference; that shouldn't change:
A a = new A;
a.func(foo = 3);// ok
a.func(bar = 3);// Error, argument name does not match parameter name
B b = new B;
b.func(foo = 3);// Error, argument name does not match parameter name
b.func(bar = 3);// ok
A c = new B;
c.func(foo = 3);// ok
c.func(bar = 3);// Error
Re: Pretty please: Named arguments
On 2/28/11 5:59 AM, spir wrote: +++ Make things simple! Since positional arguments is the main & historic parameter-passing method, just keep order. I think that would remove a huge chunk of the utility of having named arguments, and it doesn't make things easier at all from the compiler's perspective. Consider: Declaration: void func(int a = 0, int b = 1); Call: func(b: 3); // a is default Since b in the call is not in the same position as specified in the declaration (position 0 instead of position 1), the compiler already has to ignore the positioning of named arguments.
Re: Pretty please: Named arguments
On 2/28/11 5:11 AM, bearophile wrote: In recent C# versions: http://msdn.microsoft.com/en-us/library/dd264739.aspx http://geekswithblogs.net/michelotti/archive/2009/01/22/c-4.0-named-parameters-for-better-code-quality.aspx ) I had no idea C# had adopted this feature. Thanks! Looking through that first link, it looks like their rules are very nearly a match for what I came up with; the only difference I can see is that they'd prohibit the use of positional arguments following a named argument (even if the named argument is in the expected position). My argument in favor of named positional arguments (after which you *can* continue to specify positional arguments) is that the name becomes a compiler-verified annotation.
Re: Pretty please: Named arguments
On 2/28/11 5:48 AM, Andrei Alexandrescu wrote: One more thing, order of evaluation should still be left-to-right, not in order of arguments. This means the feature cannot be a syntactic rewrite (not a big issue, but definitely something to keep in mind). Andrei I was thinking that order of evaluation should remain lexically left-to-right at the point of call (that is, in the order the arguments are specified, with any remaining default parameters coming after); is there a reason that would be bad or wouldn't work?
Re: Pretty please: Named arguments
On 2/28/2011 12:04 AM, Jonathan M Davis wrote: You could be linking to code where you don't _have_ the source and don't _have_ the names of the variables. It's all done by the function signature in C, C++, Java, C#, D, etc. The names of the variables are completely irrelevant to calling the function, and so any linkers that follow C conventions (as with happens with D) _must_ be able to deal with function calls based on their signatures. That doesn't necessarily mean that it would be _impossible_ to find a way to have named arguments in D, but it makes it _far_ harder. - Jonathna M Davis Again, I don't see why that's a problem; you can't call a function if you don't have a function declaration somewhere (perhaps in a .di file). The compiler would do parameter name lookup based on the current module's view of the function space. If you truly don't have a declaration, then that means you're calling through a function pointer or a delegate. Again, no problem: either a) the function pointer or the delegate specifies names for the arguments, or b) it doesn't, in which case you simply can't use named arguments. I'm absolutely not suggesting that parameter names should be part of the ABI, nor am I suggesting that function declarations must present parameter names; if names aren't available to the module at compile time, then you can't use named arguments. Where's the problem?
Re: Pretty please: Named arguments
On 2/27/2011 11:32 PM, Russel Winder wrote: The Python mechanism relies on the fact that despatch is by name and not by signature. Languages that dispatch by signature will have significantly greater problems! I don't follow; the compiler has to look up the correct function signature whether you use named arguments or not. How is this significantly different?
Pretty please: Named arguments
Consider the following line from a project I'm playing around with:
HRESULT hr = m_Device.Present(null, null, null, null);
Quick: What behavior does that third argument specify? If you said,
"Well, /obviously/, that's a handle to an alternative destination window
for the render operation; by passing null, you're choosing not to
provide an alternative render target." then... well, gee, I have no
answer to that.
With named arguments, it becomes a bit easier to understand:
HRESULT hr = m_Device.Present(pSourceRect: null, pDestRect: null,
hDestWindowOverride: null, pDirtyRegion: null);
If I remember right, Python has this (optional) feature; I'm not aware
of anyone ever complaining about it. It also nicely provides a solution
to the bool argument problem:
http://blogs.msdn.com/b/oldnewthing/archive/2006/08/28/728349.aspx
But wait, there's more!
Named arguments get a +1 synergy bonus with default arguments. When
using parameter names to specify arguments, the order in which those
arguments are passed no longer matters. Imagine if the Present() method
above provided the default argument null for each parameter:
interface IDirect3DDevice9 : IUnknown
{
...
HRESULT Present(const(RECT)* pSourceRect = null, const(RECT)* pDestRect
= null, HWND hDestWindowOverride = null, const(RGNDATA)* pDirtyRegion =
null);
...
}
We can do this in the D binding without running afoul of any linkage
issues, and it simplifies the Present() call for its most common usage,
which I think is a good thing. Now, let's say I'm doing something
special; suppose I'm not worried about source and destination rectangles
or dirty regions, but I do want to supply a different render target.
With named arguments, that's easy to do without making things messy:
HRESULT hr = m_Device.Present(hDestWindowOverride: hOverride);
Named arguments should also play nicely with positional arguments:
auto wrappedString = wrap(reallyLongString, colmuns: 120, tabsize: 4);
Lastly, wouldn't be an entirely new feature; D already supports named
arguments for static struct initializers. I merely propose sharing the
love with normal functions and struct literals.
Here are the rules I have in mind:
1) Named arguments are not a replacement for positional arguments.
Arguments fall into three categories: positional, named positional, and
named non-positional. An argument is positional if no name is supplied.
An argument is named positional if a name is supplied and its position
matches the parameter's position in the function declaration. An
argument is named non-positional if a name is supplied and either a) its
position does not match the parameter's position in the function
declaration, or b) it is immediately preceded by a named non-positional
argument.
2) No positional argument may appear after a named non-positional argument.
3) Named non-positional arguments may appear in any order.
Potential problems: The only problems I can foresee here are variations
on the situation when there are two (or more) versions of a function
with the same number, type, and names of parameters, but in non-matching
order, like this:
void func(int a, char b);
void func(char b, int a);
In such a case, the compiler should diagnose an error if named arguments
are employed.
Thoughts?
Re: Feature request: "noexport" keyword
On 2/19/2011 11:30 PM, Nick Sabalausky wrote: "Bekenn" wrote in message news:ijqffm$6lk$1...@digitalmars.com... I'm not 100% certain, but I think this should already do what you want: export extern (Windows): void func1(); int func2(); public: void func3(); void func4(); Hmm... I think you may be right. I hadn't considered that, but it makes sense. I was thinking that the "export" attribute was independent of the other protection attributes, which would introduce an asymmetry: private, package, and public could each be overridden by supplying a different protection attribute, but export couldn't be overridden. However, thinking about it, a "private export" wouldn't make much sense (and "export" is listed as a protection attribute, right along with the others), so I guess they must all be mutually exclusive. I just tested this by trying to compile a module with the following line: public export void func(); The compiler rejects it with the message "redundant protection attribute." I think that pretty clearly settles this issue.
Feature request: "noexport" keyword
The "export" keyword is a protection attribute, along with "private",
"package", "protected", and "public". This means that it can be used
with the same syntax as any of those other attributes; for instance, if
creating a D "header" for an existing Windows DLL file, you might do
something like this:
export extern (Windows):
void func1();
int func2();
...
This notation is convenient when dealing with a very large existing
library; it avoids pointless repetition, and there's no need to keep
track of a closing end brace (as there would be with the scoped version).
The problem here is that there is no way to cancel an export attribute.
Whereas the other protection attributes can be overridden either locally:
public:
void func1();
package int func2();
...or globally:
public:
void func1();
package:
int func2();
...or with a scoped declaration, there is no way to specify that a given
symbol should *not* be exported once the "export:" version is used, or
inside a scoped export section.
A "noexport" keyword would be useful in these situations, if for
instance you want to add very small convenience functions that are
intended to be inlined and are not actually exported members of the DLL:
export extern (Windows):
void func1();
int func2();
const(char)* func3(int arg1, int arg2, const(char)* arg3, float arg4,
int arg5, void* arg6);
noexport const(char)* simpleFunc3(arg3, arg5, arg6) { return func3(0,
0, arg3, 3.14, arg5, arg6);
void func4();
...
Currently, to get the same effect, you have to either declare
simpleFunc3 above the export: line, use a scoped export block, or put
simpleFunc3 in an entirely different file. None of these provide the
same level of convenience.
What do you guys think?
Re: Feature requests
On 2/19/2011 6:57 PM, Nick Sabalausky wrote: "Andrei Alexandrescu" wrote in message news:ijpogm$29au$1...@digitalmars.com... On 2/19/11 6:35 PM, Bekenn wrote: Hello, I'm new here. I've read through some of the archives, but it's unclear to me if this is the correct place to propose and discuss new language features; would someone point me in the right direction? This is definitely the right place. Welcome and thanks for the kind words! Yea, the standard procedure is to post here and then everyone will do their best to disagree as much as possible over it, veer way offtopic, and then arrive at no overall consensus ;) Welcome to the fun! :) (I don't mean this as a sarcastic insult of this group, just kinda poking fun at it.) Ah, great; thanks, guys!
Feature requests
Hello, I'm new here. I've read through some of the archives, but it's unclear to me if this is the correct place to propose and discuss new language features; would someone point me in the right direction? I've been playing around with the language for a few weeks now, and I have to say I'm mighty impressed. I think I'll be using this for my own personal non-professional development purposes from here on out (only because I doubt I could convince my clients to switch). It's as if the designers took my list of annoyances and problems with C++, added their own equally-sized and equally valid list, and then fixed almost every single item. Thanks for a great language, guys!
