Re: problem with size_t and an easy solution
On Thu, 11 Dec 2014 05:56:23 + Ivan Kazmenko via Digitalmars-d digitalmars-d@puremagic.com wrote: On the other hand, I'm fine with the current state, and without evidence from your side, it's not going to change. So the inversion of who should bring proofs is also a false claim. it's not going to change even if god himself comes from the skies and tell to do that. there always be some random reddit user who is far superior. signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Wednesday, 10 December 2014 at 01:21:58 UTC, Mike Parker wrote: So you should be importing core.stdc.stdint directly. Pretend that std.stdint doesn't exist. I am.
Re: problem with size_t and an easy solution
On Wednesday, 10 December 2014 at 02:15:04 UTC, ketmar via Digitalmars-d wrote: On Tue, 09 Dec 2014 17:28:15 + Ivan Kazmenko via Digitalmars-d digitalmars-d@puremagic.com wrote: A well-designed language allows to recover from errors with good probability if compiler can recover from error, it should not report the error at all -- 'cause it can fix the code for me. that is absolutely nonsense, you *CAN'T* recover from invalid code. that is the fact. fact: Earth is not a sphere. fact: you can't automatically recover from invalid code. That sounds much like an opinion, a lot less like a fact. If you are willing to convince people, please provide some evidence, aside from another unrelated fact. If you guess the right recovery in, say, 99% of cases, few would care that it's theoretically impossible in the general case. In my experience, I find multiple reported compile errors useful in a number of programming languages and compilers including D. It allows for somewhat faster error fixing than the first-error-only reporting strategy - seen that, too, back in the Borland Pascal MS-DOS IDE and few other compilers. I won't trade the extra benefit just for philosophical notions.
Re: problem with size_t and an easy solution
On Wed, 10 Dec 2014 10:36:22 + Ivan Kazmenko via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wednesday, 10 December 2014 at 02:15:04 UTC, ketmar via Digitalmars-d wrote: On Tue, 09 Dec 2014 17:28:15 + Ivan Kazmenko via Digitalmars-d digitalmars-d@puremagic.com wrote: A well-designed language allows to recover from errors with good probability if compiler can recover from error, it should not report the error at all -- 'cause it can fix the code for me. that is absolutely nonsense, you *CAN'T* recover from invalid code. that is the fact. fact: Earth is not a sphere. fact: you can't automatically recover from invalid code. That sounds much like an opinion, a lot less like a fact. If you are willing to convince people, please provide some evidence, aside from another unrelated fact. the ones who believes that recovery covers most of the cases should bring proofs, not me. it's obvious that guessing on invalid input is unreliable. In my experience, I find multiple reported compile errors useful in a number of programming languages and compilers including D. It allows for somewhat faster error fixing than the first-error-only reporting strategy - seen that, too, back in the Borland Pascal MS-DOS IDE and few other compilers. I won't trade the extra benefit just for philosophical notions. most of the bugs compiler reports can be catched by good IDE without compiling the source at all. what's left is bugs where all hell breaks loose due to things that can't be recovered (like missing brackets, for example -- and ah, that can be catched by IDE too!), thus producing a pool of vomit. and with fast compiler there is no sense in vomiting, as you physically can't edit two code fragments simultaneously, thus you *will* fix bugs one by one. and go to next bug hotkey can simply invoke fast compiler to get another error message. last, but not least: recovering attempts increases parser complexity. signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Wednesday, 10 December 2014 at 10:59:17 UTC, ketmar via Digitalmars-d wrote: that is absolutely nonsense, you *CAN'T* recover from invalid code. that is the fact. fact: Earth is not a sphere. fact: you can't automatically recover from invalid code. That sounds much like an opinion, a lot less like a fact. If you are willing to convince people, please provide some evidence, aside from another unrelated fact. the ones who believes that recovery covers most of the cases should bring proofs, not me. it's obvious that guessing on invalid input is unreliable. Fine, I don't have the hard proof at hand, since my compilation-error state programs don't tend to go into version control systems. Perhaps I can track them too if such statistics can be shown to have some real value. On the other hand, I'm fine with the current state, and without evidence from your side, it's not going to change. So the inversion of who should bring proofs is also a false claim.
Re: problem with size_t and an easy solution
On Tuesday, 9 December 2014 at 03:48:17 UTC, ketmar via Digitalmars-d wrote: i can remember that too, but i prefer to have the things that i can logically deduce. i can deduce `usize`: ah, it's size. and it's unsigned. D tends to add 'u' for unsigned types and naming 'size' as 'size' is logical. so it must be 'usize'. hit! Size is unsigned for being positive. Why emphasize it again? 'u' prefix is for general purpose integers, size_t is a special purpose type for specific case of representing sizes, similar types are time_t, off_t and hash_t in a sense that representation can change, but purpose will remain the same.
Re: problem with size_t and an easy solution
On Tue, 09 Dec 2014 08:26:18 + Kagamin via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 9 December 2014 at 03:48:17 UTC, ketmar via Digitalmars-d wrote: i can remember that too, but i prefer to have the things that i can logically deduce. i can deduce `usize`: ah, it's size. and it's unsigned. D tends to add 'u' for unsigned types and naming 'size' as 'size' is logical. so it must be 'usize'. hit! Size is unsigned for being positive. Why emphasize it again? to stop people think that they can safely subtract one size from another. that 'u' will remind them. signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Monday, 8 December 2014 at 14:31:50 UTC, ketmar via Digitalmars-d wrote: Personally, when I face the need for a size_t, I usually can (and do) use auto instead. And even if I have to spell it, I don't care too much how it's called, only whether it can be easily recognized. i bet that woobooAAARGH will be even easier to recognize than size_t. as there is no other types in D with _t suffix, you have to remember that anyway, so it doesn't really matter which one to remember. ;-) brb aliasing
Re: problem with size_t and an easy solution
On Tuesday, 9 December 2014 at 03:48:17 UTC, ketmar via Digitalmars-d wrote: http://dlang.org/phobos/std_stdint.html ah, nobody uses that, and it's not even documented. a forgotten leftover. I've just used it. It *is* part of phobos, albeit hidden.
Re: problem with size_t and an easy solution
On Tue, 09 Dec 2014 13:34:24 + Gary Willoughby via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 9 December 2014 at 03:48:17 UTC, ketmar via Digitalmars-d wrote: http://dlang.org/phobos/std_stdint.html ah, nobody uses that, and it's not even documented. a forgotten leftover. I've just used it. It *is* part of phobos, albeit hidden. ok, we have one man using it. ;-) signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Tue, 09 Dec 2014 13:34:24 + Gary Willoughby via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 9 December 2014 at 03:48:17 UTC, ketmar via Digitalmars-d wrote: http://dlang.org/phobos/std_stdint.html ah, nobody uses that, and it's not even documented. a forgotten leftover. I've just used it. It *is* part of phobos, albeit hidden. p.s. just out of curiousity: why do you need it? D int types has well-defined size, so i can't see any sense in using C leftover. signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Tuesday, 9 December 2014 at 16:10:10 UTC, ketmar via Digitalmars-d wrote: p.s. just out of curiousity: why do you need it? D int types has well-defined size, so i can't see any sense in using C leftover. I'm doing lots of pointer arithmetic so i've used uintptr_t in various places.
Re: problem with size_t and an easy solution
On Tuesday, 9 December 2014 at 03:14:23 UTC, ketmar via Digitalmars-d wrote: somehow Walter can't accept that after emiting the first error compiler is in undefined state, and trying to pretend that it is in well-defined state or guess what well-defined state must be is a nonsense. A well-designed language allows to recover from errors with good probability and thus give simultaneous useful error reports for multiple parts of the program. Sure, you always need the first error message, but having other useful error messages is a benefit as long as the probability of recovery is high enough.
Re: problem with size_t and an easy solution
D devs are quite willing to improve error messages, they have improved many of them. I'm not trying to call anyone lazy ;) Sometimes though, the bugs I imagine I would submit seem like they would lead to a wild goose chase more than a solution. Don't forget to mention DustMite. I'll definitely check this out. somehow Walter can't accept that after emiting the first error compiler is in undefined state, and trying to pretend that it is in well-defined state or guess what well-defined state must be is a nonsense. I don't think I would call this nonsense. MSVC for example, often emits multiple errors correctly. I haven't checked this with MSVC, but I imagine an unidentified identifier could be a case where this is possible. Also, many intellisense systems are able to recover after multiple errors and continue parsing a file. I suppose the rest of the errors could be generated on a second pass though. For example, if the first error was an unidentified identifier, the compiler could then re-parse the file and report all instances of that identifier's usage. D compiler is fast enough to stop that horrible now you have 100500 errors reported, enjoy practice. On the other hand, this sounds a lot like failed template instantiations in old versions of MSVC ;) the second thing that i want to have is compiler explaining why it rejected some templates. i.e. what constrains failed. those messages about can't instantiate are among the most noisy and cryptic ones. Yep.
Re: problem with size_t and an easy solution
On 12/10/2014 1:55 AM, Gary Willoughby wrote: On Tuesday, 9 December 2014 at 16:10:10 UTC, ketmar via Digitalmars-d wrote: p.s. just out of curiousity: why do you need it? D int types has well-defined size, so i can't see any sense in using C leftover. I'm doing lots of pointer arithmetic so i've used uintptr_t in various places. So you should be importing core.stdc.stdint directly. Pretend that std.stdint doesn't exist.
Re: problem with size_t and an easy solution
On Tue, 09 Dec 2014 17:28:15 + Ivan Kazmenko via Digitalmars-d digitalmars-d@puremagic.com wrote: A well-designed language allows to recover from errors with good probability if compiler can recover from error, it should not report the error at all -- 'cause it can fix the code for me. that is absolutely nonsense, you *CAN'T* recover from invalid code. that is the fact. fact: Earth is not a sphere. fact: you can't automatically recover from invalid code. that habit of try to compile as much as we can originates in the times when running a compiler was very costly process, so it's better to have some invalid error messages than runing the compiler again after each error found and fixed. hey, it's time to stop doing that! the epoch of punch cards and teletypes are over! it's time to stop trying to recover from irrecoverable states. there is *nothing* valuable in a stupid list of compilation errors most of which are invalid and others will become invalid after you fix the first one. build faster compiler. cache AST's. but stop vomiting alphanumeric noise just because... well... we doing this from 70ths! signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Tue, 09 Dec 2014 16:55:22 + Gary Willoughby via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 9 December 2014 at 16:10:10 UTC, ketmar via Digitalmars-d wrote: p.s. just out of curiousity: why do you need it? D int types has well-defined size, so i can't see any sense in using C leftover. I'm doing lots of pointer arithmetic so i've used uintptr_t in various places. ah, that one type. i was always wonder why it's missing in object.d[i]. but as `usize` is guaranteed to be big enough to hold the pointer and `alias` doesn't create any new type, why don't just use `usize`/`size_t`? signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Tue, 09 Dec 2014 18:08:48 + bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: somehow Walter can't accept that after emiting the first error compiler is in undefined state, and trying to pretend that it is in well-defined state or guess what well-defined state must be is a nonsense. I don't think I would call this nonsense. MSVC for example, often emits multiple errors correctly. I haven't checked this with MSVC, but I imagine an unidentified identifier could be a case where this is possible. Also, many intellisense systems are able to recover after multiple errors and continue parsing a file. so let intellisense-like systems do the guesswork. i don't trust a compiler that tries to guess what i mean instead of reporting the error and stop right there. i.e. i once tried PL/1 compiler which was able to guess what lone `IF` means. and now i don't want the compiler to do *ANY* guesswork. it's ok for support tools, but compiler should not claim that it can recover from invalid code, 'cause invalid code is... well... invalid and irrecoverable without manual human fixing. and if it is recoverable, why do i have to do any manual fixing at all? if compiler is so smart, he should fix the code and go on. see, you *CAN'T* recover from such error. even in D you can catch Error, but program state is already undefined. in the case of compiler the state of the compiler itself is defined, but input data is trashed. i can't see any sense in trying to figure out something sane from trashed input. let the user fix the input instead of guessing. signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
so let intellisense-like systems do the guesswork. i don't trust a compiler that tries to guess what i mean instead of reporting the error and stop right there. i.e. i once tried PL/1 compiler which was able to guess what lone `IF` means. and now i don't want the compiler to do *ANY* guesswork. I probably should have started my own thread ;) Anyways, this video is a couple of years old, but this is how Clang does what I'm talking about, around 16:00 minutes in. http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys
Re: problem with size_t and an easy solution
On Wed, 10 Dec 2014 03:00:56 + bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: so let intellisense-like systems do the guesswork. i don't trust a compiler that tries to guess what i mean instead of reporting the error and stop right there. i.e. i once tried PL/1 compiler which was able to guess what lone `IF` means. and now i don't want the compiler to do *ANY* guesswork. I probably should have started my own thread ;) ah, no, this thread is fine too. ;-) this thread is not strictly about size_t, it's about inconsistencies and legacies in D. Anyways, this video is a couple of years old, but this is how Clang does what I'm talking about, around 16:00 minutes in. http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys as i can understand from my limited english hearing skills ;-), this is about guessing identifiers, right? another feature i found useless. i even patched my DMD to stop suggesting me that BS, it's so annoying. i want command-line argument to stop DMD doing that! signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
Freddy: Why not keep size_t implictly convertable but disallow it for usize. This is an interesting idea. (But the name uword seems better). Bye, bearophile
Re: problem with size_t and an easy solution
On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote: Freddy: Why not keep size_t implictly convertable but disallow it for usize. This is an interesting idea. (But the name uword seems better). YES. And I want a signed variant of this (instead of the ugly ptrdiff_t): I want to wield my sword!
Re: problem with size_t and an easy solution
On Mon, 08 Dec 2014 11:37:00 + Dominikus Dittes Scherkl via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote: Freddy: Why not keep size_t implictly convertable but disallow it for usize. This is an interesting idea. (But the name uword seems better). YES. And I want a signed variant of this (instead of the ugly ptrdiff_t): I want to wield my sword! uword is meaningless, and usize is meaningfull. but i like sword... yet i used to 16-bit words. signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote: Freddy: Why not keep size_t implictly convertable but disallow it for usize. This is an interesting idea. (But the name uword seems better). The char, wchar (word char) and dchar (double word char) types seem to disagree. The word=2bytes historical rule is rooted too deeply. An uword will also be very confusing alongside lower level code (e.g. assembler). Personally, when I face the need for a size_t, I usually can (and do) use auto instead. And even if I have to spell it, I don't care too much how it's called, only whether it can be easily recognized.
Re: problem with size_t and an easy solution
On Monday, 8 December 2014 at 11:49:47 UTC, ketmar via Digitalmars-d wrote: On Mon, 08 Dec 2014 11:37:00 + Dominikus Dittes Scherkl via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote: Freddy: Why not keep size_t implictly convertable but disallow it for usize. This is an interesting idea. (But the name uword seems better). YES. And I want a signed variant of this (instead of the ugly ptrdiff_t): I want to wield my sword! uword is meaningless, and usize is meaningfull. but i like sword... yet i used to 16-bit words. This is just my opinion and I could be persuaded otherwise but word/uword seem nicer. It seems more descriptive, the size of a word on the system. Also I see less potential for name conflicts. The type size will probably conflict with alot of symbol names (function names/variables/etc). I would be willing to bet this is why C/C++ initially used size_t instead of size in the first place.
Re: problem with size_t and an easy solution
On Mon, 08 Dec 2014 14:00:25 + Jonathan Marler via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 8 December 2014 at 11:49:47 UTC, ketmar via Digitalmars-d wrote: On Mon, 08 Dec 2014 11:37:00 + Dominikus Dittes Scherkl via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote: Freddy: Why not keep size_t implictly convertable but disallow it for usize. This is an interesting idea. (But the name uword seems better). YES. And I want a signed variant of this (instead of the ugly ptrdiff_t): I want to wield my sword! uword is meaningless, and usize is meaningfull. but i like sword... yet i used to 16-bit words. This is just my opinion and I could be persuaded otherwise but word/uword seem nicer. It seems more descriptive, the size of a word on the system. Also I see less potential for name conflicts. The type size will probably conflict with alot of symbol names (function names/variables/etc). I would be willing to bet this is why C/C++ initially used size_t instead of size in the first place. ah, there can't be size type, only usize. we can't have list or array with -3 items. ;-) and even if we want signed size, this will be ssize. we already have byte instead of sbyte, it's PITA. signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Mon, 08 Dec 2014 13:49:30 + Ivan Kazmenko via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote: Freddy: Why not keep size_t implictly convertable but disallow it for usize. This is an interesting idea. (But the name uword seems better). The char, wchar (word char) and dchar (double word char) types seem to disagree. The word=2bytes historical rule is rooted too deeply. An uword will also be very confusing alongside lower level code (e.g. assembler). Personally, when I face the need for a size_t, I usually can (and do) use auto instead. And even if I have to spell it, I don't care too much how it's called, only whether it can be easily recognized. ah, well, there are `ptrdiff_t` and `hash_t`, both of the same uglyness. signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Mon, 08 Dec 2014 13:49:30 + Ivan Kazmenko via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote: Freddy: Why not keep size_t implictly convertable but disallow it for usize. This is an interesting idea. (But the name uword seems better). The char, wchar (word char) and dchar (double word char) types seem to disagree. The word=2bytes historical rule is rooted too deeply. An uword will also be very confusing alongside lower level code (e.g. assembler). Personally, when I face the need for a size_t, I usually can (and do) use auto instead. And even if I have to spell it, I don't care too much how it's called, only whether it can be easily recognized. i bet that woobooAAARGH will be even easier to recognize than size_t. as there is no other types in D with _t suffix, you have to remember that anyway, so it doesn't really matter which one to remember. ;-) signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Monday, 8 December 2014 at 14:29:09 UTC, ketmar via Digitalmars-d wrote: On Mon, 08 Dec 2014 14:00:25 + Jonathan Marler via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 8 December 2014 at 11:49:47 UTC, ketmar via Digitalmars-d wrote: On Mon, 08 Dec 2014 11:37:00 + Dominikus Dittes Scherkl via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote: Freddy: Why not keep size_t implictly convertable but disallow it for usize. This is an interesting idea. (But the name uword seems better). YES. And I want a signed variant of this (instead of the ugly ptrdiff_t): I want to wield my sword! uword is meaningless, and usize is meaningfull. but i like sword... yet i used to 16-bit words. This is just my opinion and I could be persuaded otherwise but word/uword seem nicer. It seems more descriptive, the size of a word on the system. Also I see less potential for name conflicts. The type size will probably conflict with alot of symbol names (function names/variables/etc). I would be willing to bet this is why C/C++ initially used size_t instead of size in the first place. ah, there can't be size type, only usize. we can't have list or array with -3 items. ;-) and even if we want signed size, this will be ssize. we already have byte instead of sbyte, it's PITA. What about 'usize' and 'ptrdiff' ? 'ssize' seems a little ugly to me, but I realize this is just a matter of opinion. Personally I think this is a good idea, but I would be ok with multiple solutions. 'uword'/'usize' both seem ok to me. I could even live with 'ssize'. I have gotten use to using '_t' but you make a good point that since 'size_t' looks alien to D it encourages users to use the wrong type since it may look more consistent to the rest of their D code. In my opinion, size_t needs to be treated more like a first class citizen, listed with all the other native types instead of being a footnote. Maybe changing the name will help developers use it.
Re: problem with size_t and an easy solution
On Monday, 8 December 2014 at 14:31:50 UTC, ketmar via Digitalmars-d wrote: On Mon, 08 Dec 2014 13:49:30 + Ivan Kazmenko via Digitalmars-d digitalmars-d@puremagic.com wrote: Personally, when I face the need for a size_t, I usually can (and do) use auto instead. And even if I have to spell it, I don't care too much how it's called, only whether it can be easily recognized. i bet that woobooAAARGH will be even easier to recognize than size_t. as there is no other types in D with _t suffix, you have to remember that anyway, so it doesn't really matter which one to remember. ;-) Now that you say it, indeed the code won't be fancy if it goes like woobooAAARGH len = name.length; I'll go with an auto here, or yet another type alias. Perhaps I don't have strong feelings against size_t because I like old_c_style_variable_names more than theNewShinyCamelCase. It's just a personal preference.
Re: problem with size_t and an easy solution
FWIW, I picked hp D ~2 months ago, and my first project was a reflection library, so I've had a chance to deal with most of the language features at least once so far. The naming and presence of legacy C++ was a little strange, but I would leave it at that. What was by FAR the most confusing/frustrating thing was the vague, and many times, completely wrong or misleading compiler error messages. If time was to be spent anywhere, I think that would be most helpful. I would quote a few of these error messages, but I wouldn't be able to reproduce them, as I have no idea why they occurred in the first place..
Re: problem with size_t and an easy solution
On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote: Freddy: Why not keep size_t implictly convertable but disallow it for usize. This is an interesting idea. (But the name uword seems better). Bye, bearophile As a legacy from 16-bit era word is ushort. I use intp and uintp.
Re: problem with size_t and an easy solution
On Monday, 8 December 2014 at 01:30:35 UTC, ketmar via Digitalmars-d wrote: Hello. i don't like `size_t`. for many month i avoied using it wherever that was possible, 'cause i feel something wrong with it. size_t is not too bad, it's not as alien as you may think as there is also std.stdint. http://dlang.org/phobos/std_stdint.html Personally i don't have any issue with the naming as long as i know what each type represents.
Re: problem with size_t and an easy solution
bitwise: I would quote a few of these error messages, but I wouldn't be able to reproduce them, as I have no idea why they occurred in the first place.. You don't need to know what caused them, you have to copy your code, minimize it progressively keeping the error message unchanged, and submit it to bugzilla. D devs are quite willing to improve error messages, they have improved many of them. Bye, bearophile
Re: problem with size_t and an easy solution
On Monday, 8 December 2014 at 17:38:42 UTC, bearophile wrote: bitwise: I would quote a few of these error messages, but I wouldn't be able to reproduce them, as I have no idea why they occurred in the first place.. You don't need to know what caused them, you have to copy your code, minimize it progressively keeping the error message unchanged, and submit it to bugzilla. D devs are quite willing to improve error messages, they have improved many of them. Bye, bearophile Don't forget to mention DustMite. A simple yet elegent solution to assist in minimizing the code. It comes packaged with the DMD compiler so you probably already have it installed:)
Re: problem with size_t and an easy solution
On Mon, 08 Dec 2014 15:52:07 + bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: FWIW, I picked hp D ~2 months ago, and my first project was a reflection library, so I've had a chance to deal with most of the language features at least once so far. The naming and presence of legacy C++ was a little strange, but I would leave it at that. What was by FAR the most confusing/frustrating thing was the vague, and many times, completely wrong or misleading compiler error messages. If time was to be spent anywhere, I think that would be most helpful. I would quote a few of these error messages, but I wouldn't be able to reproduce them, as I have no idea why they occurred in the first place.. ah, the thing that now got the official commit: stop after N errors. just make the compiler stop after exactly one error, and most strange error messages will go away. somehow Walter can't accept that after emiting the first error compiler is in undefined state, and trying to pretend that it is in well-defined state or guess what well-defined state must be is a nonsense. D compiler is fast enough to stop that horrible now you have 100500 errors reported, enjoy practice. the second thing that i want to have is compiler explaining why it rejected some templates. i.e. what constrains failed. those messages about can't instantiate are among the most noisy and cryptic ones. signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Mon, 08 Dec 2014 15:05:18 + Jonathan Marler via Digitalmars-d digitalmars-d@puremagic.com wrote: What about 'usize' and 'ptrdiff' ? `sptrdiff`, as i did it in my branch. `ssize` was just an example, i don't like it too. yet `sptrdiff` is still ugly. why 'ptr', what it has to do with pointers at all? why, for example, `indexOf()` returns `ptrdiff_t`? btw, this is a bug, 'cause that means that i can't search more than 2GB in 32-bit and get a sane result on hit, for example. something like 'ssizediff' is slightly better, i think. we have no explicit ptr type, and using `ptrdiff_t` when subtracting pointers is wrong anyway (only `uptrdiff_t` can do there, but we already has `usize` for it). or, doing it *right* this time: just annihilate `ptrdiff_t`. it's dangerous and useless. signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Mon, 08 Dec 2014 15:39:53 + Ivan Kazmenko via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 8 December 2014 at 14:31:50 UTC, ketmar via Digitalmars-d wrote: On Mon, 08 Dec 2014 13:49:30 + Ivan Kazmenko via Digitalmars-d digitalmars-d@puremagic.com wrote: Personally, when I face the need for a size_t, I usually can (and do) use auto instead. And even if I have to spell it, I don't care too much how it's called, only whether it can be easily recognized. i bet that woobooAAARGH will be even easier to recognize than size_t. as there is no other types in D with _t suffix, you have to remember that anyway, so it doesn't really matter which one to remember. ;-) Now that you say it, indeed the code won't be fancy if it goes like woobooAAARGH len = name.length; I'll go with an auto here, or yet another type alias. that is exactly the feeling `size_t` summons. it's unnatural for D. Perhaps I don't have strong feelings against size_t because I like old_c_style_variable_names more than theNewShinyCamelCase. It's just a personal preference. i used both styles in C, one with underscores for last years. but here i'm talking about consistency, the thing which D community tends to ignore. having `uint`, `ulong` and `size_t` is inconsistent. it should be either `uint_t`, `ulong_t` (and `usize_t` for that matter), or `uint`, `ulong` and `usize`. i really don't care if it will be '_t'-suffixed or not, i simply want it to be consistent. signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Mon, 08 Dec 2014 16:03:42 + Kagamin via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote: Freddy: Why not keep size_t implictly convertable but disallow it for usize. This is an interesting idea. (But the name uword seems better). Bye, bearophile As a legacy from 16-bit era word is ushort. I use intp and uintp. i think that `intp` and `uintp` is very good. a little hard to read maybe (too similar to `int` and `uint`). signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Mon, 08 Dec 2014 17:33:48 + Gary Willoughby via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 8 December 2014 at 01:30:35 UTC, ketmar via Digitalmars-d wrote: Hello. i don't like `size_t`. for many month i avoied using it wherever that was possible, 'cause i feel something wrong with it. size_t is not too bad, it's not as alien as you may think as there is also std.stdint. http://dlang.org/phobos/std_stdint.html ah, nobody uses that, and it's not even documented. a forgotten leftover. Personally i don't have any issue with the naming as long as i know what each type represents. i can remember that too, but i prefer to have the things that i can logically deduce. i can deduce `usize`: ah, it's size. and it's unsigned. D tends to add 'u' for unsigned types and naming 'size' as 'size' is logical. so it must be 'usize'. hit! i can't do that for `size_t`, though. the only thing i can do with it is to remeber it. and i'm very bad in remembering nonsensical things. signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Monday, 8 December 2014 at 01:30:35 UTC, ketmar via Digitalmars-d wrote: Hello. i don't like `size_t`. for many month i avoied using it wherever that was possible, 'cause i feel something wrong with it. and today i found the soultion! let's see how other D types are named: `int`, `uint`, `byte` (oh, well, this name sux), `ulong`. see the pattern? so i decided to rename `size_t` to `usize`. and you know what? it immidiately started to be familiar. like a thing that was always here, simply dressed in patches. let's face it: that ugly '_t' is alien to D. this is an ugly leftover from C, and this leftover is nonsence. it will not really help anyone, but it immideately turns D code to badly-looking crap. see for yourself: size_t countSomeElements(); and usize countSomeElements(); `size_t` looking like an alien here, ruining all the style. i propose to introduce `usize` and `sptrdiff` along with those '_t' uglyness, and then slowly migrate all the code to the new names. yes, this is another cosmetic issue, but let me tell you that such purely cosmetic things are really important for those who just starting to learn the language. it's impossible to write nice D code with `size_t`: we have either alias it each time or use `uint`/`ulong` to make our code looks good. really, i've seen people who using `uint` instead of `size_t`, 'cause with size_t my code looks ugly, and i tired of aliasing that shit every time. ah, yep, their code sux for 64 bits, but: i know that 64-bit size_t is... 64-bit. i'll fix that later, maybe. uglyness leads to bad code. let's kill `size_t` for good! p.s. some of you may think that i'm trolling. i can assure you that this post is not trolling, this is just another try to talk about purely cosmetic issues and how they hurts the language, especially for beginners. when beginner see such pure cosmetic issue, he starting to think that the whole language is a mess: hey, this is such easy to fix, but they never bother to... i bet the other parts of the language are even worse. and you know what? it's enough to make such mistake two or three times to make people believe that D is a dirty and hackish language without clear style. this is gly is *the* *argument*. I would like if usize wasn't implictly convertable to uint or ulong
Re: problem with size_t and an easy solution
On Mon, 08 Dec 2014 01:50:44 +
Freddy via Digitalmars-d digitalmars-d@puremagic.com wrote:
I would like if usize wasn't implictly convertable to uint or
ulong
me too, but this change is too radical. it will not break any of my
own code ('cause i used to write casts for that stupid 64-bit systems to
shut up), but i doubt that other people will agree with such change.
signature.asc
Description: PGP signature
Re: problem with size_t and an easy solution
On Monday, 8 December 2014 at 02:04:58 UTC, ketmar via
Digitalmars-d wrote:
On Mon, 08 Dec 2014 01:50:44 +
Freddy via Digitalmars-d digitalmars-d@puremagic.com wrote:
I would like if usize wasn't implictly convertable to uint or
ulong
me too, but this change is too radical. it will not break any
of my
own code ('cause i used to write casts for that stupid 64-bit
systems to
shut up), but i doubt that other people will agree with such
change.
Why not keep size_t implictly convertable but disallow it for
usize.
Re: problem with size_t and an easy solution
On Mon, 08 Dec 2014 02:29:49 +
Freddy via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Monday, 8 December 2014 at 02:04:58 UTC, ketmar via
Digitalmars-d wrote:
On Mon, 08 Dec 2014 01:50:44 +
Freddy via Digitalmars-d digitalmars-d@puremagic.com wrote:
I would like if usize wasn't implictly convertable to uint or
ulong
me too, but this change is too radical. it will not break any
of my
own code ('cause i used to write casts for that stupid 64-bit
systems to
shut up), but i doubt that other people will agree with such
change.
Why not keep size_t implictly convertable but disallow it for
usize.
'cause there is no such type as `size_t` (and `usize` for that matter).
`size_t` is defined as the alias for the corresponding unsigned
integral type, and so i did with `usize`.
so both `size_t` and `usize` are actually `uint`/`ulong`. so they not
just convertible, they are the same type.
signature.asc
Description: PGP signature
