ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
cenomla has quit [Remote host closed the connection]
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 252 seconds]
arBmind has quit [Ping timeout: 240 seconds]
_whitelogger has joined #zig
Elronnd has quit [Ping timeout: 276 seconds]
Elronnd has joined #zig
tiehuis has joined #zig
<GitHub14>
[zig] tiehuis opened pull request #542: Add c allocator (master...c_allocator) https://git.io/vdy5P
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 252 seconds]
pupp has joined #zig
puppp has joined #zig
pupp has quit [Read error: Connection reset by peer]
<PV_>
Yeah, this works, but still. CR/LF is Windows standard, why to fight against it? Simple copy/paste doesn't work. Anyone new trying will be disappointed at the first moment.
<andrewrk>
it's a fair argument
<andrewrk>
let me think about it
<andrewrk>
one complication is multiline strings use LF
hoppetosse has joined #zig
<andrewrk>
I mean it's simple now; only LF works. But it becomes complicated if we try to also support CRLF
<PV_>
Where could I report error and inconsistencies? Perhaps there could be single bug issue for every release, not to clutter bug tracker too much.
<andrewrk>
PV_, a bug report for every independent problem is OK. I'll categorize them as necessary
<_dev_zero>
including implicit \r in multiline strings sounds unwise. just ignoring it wouldn't work?
<andrewrk>
_dev_zero, do you suggest manually terminating lines with \n in multiline strings?
hoppetosse has quit [Ping timeout: 260 seconds]
pupp has joined #zig
<andrewrk>
are you familiar with how it works currently?
<_dev_zero>
this is quite new to me, so honestly not really
<_dev_zero>
but as far as I understand, multiline strings are currently implcitly include newlines
<_dev_zero>
s/are //
<_dev_zero>
so kind of yeah, even if if you get \r\n you'd include only \n
<_dev_zero>
s/if //
<_dev_zero>
I do not suggest forcing programmer to manually type \n though, if you meant that by "manually"
<pupp>
personally I pretend that /r/n doesn't exist. The only program that really depends on it is default windows notepad. Everything else can work with /n
<pupp>
but if people need it...
<andrewrk>
I'm not convinced that people need it
<pupp>
I hope there will be an easy way to remove that from code later
<_dev_zero>
some editors are really bad at pointing out distinction
<_dev_zero>
especially in windows land
<_dev_zero>
where lots of stuff assume \r\n
<pupp>
examples of lots?
<pupp>
just curious
<_dev_zero>
me too actually. I'm not really windows user but I remember most of my text files having \r\n somehow back when I used it
<_dev_zero>
that's also because in windows stdio functions insert additional \r
arBmind has quit [Quit: Leaving.]
<andrewrk>
_dev_zero, you're talking about printf and _setmode
<andrewrk>
now that you mention it, yes I think it is on a file descriptor level
<_dev_zero>
it happens for every writing function if it's opened in non-binary mode