On Wednesday, 21 June 2017 at 03:57:46 UTC, ketmar wrote:
> "bloatsome"? i don't think so. those generated messages is small (usually 20-30 bytes), and nothing comparing to druntime/phobos size.

Yeah, but what if you're already working without runtime and phobos?
(some embedded systems only have 32Kb program memory, and yes these are up-to-date ones)

Would it help to formalize the interface between compiler generated code and druntime? (IIRC this is implementation specific at the moment).

The idea is to make it easier to only reimplement and provide the runtime parts that are actually needed ; and to rely on link errors to prevent forbidden D constructs.

Sebastien Alaiwan wrote:

> On Wednesday, 21 June 2017 at 03:57:46 UTC, ketmar wrote:
>> "bloatsome"? i don't think so. those generated messages is small (usually 20-30 bytes), and nothing comparing to druntime/phobos size.
>
> Yeah, but what if you're already working without runtime and phobos?

it doesn't matter, `assert()` is impemented as `throw` anyway. and in "betterc" mode compiler can just omit generation of such messages, resorting to what it does now.

> (some embedded systems only have 32Kb program memory, and yes these are up-to-date ones)

asserts on embedded systems? O_O code built without -release for embedded systems? O_O

On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote:
> Is getting a whole lot better:
>
> https://github.com/dlang/dmd/pull/6918
>
> You can now build D executables that do not link in anything from Phobos - only from the standard C library.

https://www.reddit.com/r/programming/comments/6ijwek/dlangs_dmd_now_compiles_programs_in_betterc_mode/

On Wednesday, 21 June 2017 at 05:35:42 UTC, ketmar wrote:
> asserts on embedded systems? O_O code built without -release for embedded systems? O_O

embedded system != production system.

You still need to debug the code, and at some point, you have to load it on a real microcontroller ; this is where some of your assumptions about how the chip works might turn out to be false.

This is where it gets tricky. Because now you need to fit the memory requirements, and at the same time, you want some level of diagnostic.

And by the way, you might want to keep boundschecking code, even in production. In some situations, it's preferable to crash/hang than outputing garbage.

Sebastien Alaiwan wrote:

> On Wednesday, 21 June 2017 at 05:35:42 UTC, ketmar wrote:
>> asserts on embedded systems? O_O code built without -release for embedded systems? O_O
>
> embedded system != production system.
>
> You still need to debug the code, and at some point, you have to load it on a real microcontroller ; this is where some of your assumptions about how the chip works might turn out to be false.

as i said, in "betterc" mode compiler can omit generation of assert condition strings.

but refusing to generate such strings for *all* code in favor of embedded cases is like "let's remove classes and exceptions from D, 'cause they're too costly for embedded code!"

On 2017-06-20 23:30, Guillaume Piolat wrote:

> Good move from Apple.
> I distribute both bitness as Universal Binaries, most probably this will still work.

Yes, as long as the tools continue to support it.

-- 
/Jacob Carlborg

On 2017-06-20 22:44, Walter Bright wrote:

> For a C implementation that doesn't support TLS, using it in D with -betterC won't work.

I'm thinking more of a C implementation where it *does* work. But perhaps you're not expected to do anything besides what you can do in C when it comes to TLS.

-- 
/Jacob Carlborg

On 6/20/2017 11:54 PM, Jacob Carlborg wrote:
> On 2017-06-20 22:44, Walter Bright wrote:
> 
>> For a C implementation that doesn't support TLS, using it in D with -betterC won't work.
> 
> I'm thinking more of a C implementation where it *does* work. But perhaps you're not expected to do anything besides what you can do in C when it comes to TLS.


It does work with C on Windows, Linux, OSX, and FreeBSD, and so it works with -betterC, too.

On Wednesday, 21 June 2017 at 06:21:37 UTC, ketmar wrote:
> but refusing to generate such strings for *all* code

They are not useful enough for that, in 99% of cases location of assert is enough to know what's wrong, when it isn't, the string is not going to tell where it went wrong, so you need to debug it, in which case there's no difference again. Don't fluent asserts already do what you want? See http://fluentasserts.szabobogdan.com/

Kagamin wrote:

> On Wednesday, 21 June 2017 at 06:21:37 UTC, ketmar wrote:
>> but refusing to generate such strings for *all* code
>
> They are not useful enough for that, in 99% of cases location of assert is enough to know what's wrong, when it isn't, the string is not going to tell where it went wrong, so you need to debug it, in which case there's no difference again.

there, of course, *IS* The difference. besides the aesthetical one (seeing failed condition immediately "clicks" in your head, and generic "assertion failed" message is only frustrating), there may be the case when source code changed since binary was built. here, line number gives you zero information, and you have to checkout that exact version, and go check the line. but when failed condition dumped, most of the time it allows you to see what is wrong even without switching to the old codebase (yes, "most of the time" is from RL -- it is literally *most* of the time for me, for example).


> Don't fluent asserts already do what you want? See http://fluentasserts.szabobogdan.com/

nope. those aren't assertions at all, compiler cannot even remove 'em with "-release" flag (not that i'm using it much, but still no, thanks).

mind you, assertions is not only for unittesting.