If you did have a JSON date, how would you decide what it was? Would it be a timestamp, or a civil date-time? Would it have timezones? Offsets? Locations? Would there be a database along with it required to understand it correctly?
Just stick with ISO8601 strings.
You could make the same argument with numbers - there's no reason you couldn't just pass strings containing the number - but there's advantages to being able to distinguish between a string and a number when the schema is unknown.
The reason JSON doesn't have dates is simply because JavaScript doesn't have date literals. You can write new Date(...) in JavaScript, but allowing that in JSON would have opened a whole can of worms.
If you mean a 64-bit integer type (which, to be fair, is 11 bits larger than what JavaScript supports), then that's still not enough. As long as you want nanosecond-level granularity, and range beyond the current decade for your timestamps, you'll need more than 8 bytes to represent them in code.
const res = await fetch(url);
const data = await res.json();
It does not do it automatically. Even in your example, you call `Response.json()` to do the parsing. If you change that to `Response.text()` it will be text instead. If you don't include the `.json()` call, nothing will be parsed from the body.
I don't follow what it would use function strings for determining missing - presumably - polyfills that you couldn't do in better ways.
One thing that I am a bit afraid about though is that the language might become more complex and complicated over time because of backward compatibility (C++-like?). I saw that they will be introducing a new function "replaceAll(...)" to avoid the weird semantics of "replace(...)" (stopping after first occurrence unless a 'global' RegExp is passed as argument). And that's great, but that's a new function, and maybe 'replace(...)' should have had this behavior from the start. I hope to be wrong on this one!
C++ doesn't actually need it. Rust proved that capture everything by reference or capture everything by move is enough for all practical use cases.
C++ lambdas is another example where C++ committee chose complex uber-universal solution instead of much simpler which solves 99% use cases.
New methods with simple behaviour don't really make the language more complex through.
> And that's great, but that's a new function, and maybe 'replace(...)' should have had this behavior from the start.
As you note it kinda does, just in a weird roundabout manner.
One issue with javascript is also that it makes extending existing functions difficult, because extra arguments are just ignored by default, so you can't just add a `count=1` parameter to String.replace to override the regex flag as there could be code out there which already passes a third (currently ignored) parameter and would break.
I think they do, in some ways. If you have multiple methods or functions which seem to do similar things, as a new-comer it can be incredibly confusing. I remember when I started I never knew what the "best way" to iterate on things was... for loops? for in? for of? foreach? And it was not obvious which one to use or what were the differences. I agree that it might be less ambiguous between "replace" and "replaceAll", but I think over time these things matter.
Like I wonder how many bugs were introduced because the developer didn’t realize Array.sort() was unstable.
[1,2,10].sort()
If the comparison function argument was mandatory in sort() this wouldn’t be a problem.
Hell, really?? That's gross.
As for the parent's comment about a dev "not realising array.sort() was unstable", the dev should know his tools. I can't see anyway why a stable sort is better, I've never sorted on x then sorted on x, you just sort on x & y.
You seem to think stable sort is much more important than most of the rest of the field.
By default, C sort isn't stable, C++ sort isn't stable, Ruby sort isn't stable, C# sort isn't stable, Perl sort isn't stable. Hell, not even GNU's sort utility is stable.
JavaScript has some unexpected idiosyncracies, but sort() stability isn't one of them.
Eh... that's great and all, but why not go the whole way and allow me to just use `try { }` without a catch-block? I'm sure that was part of a conversation somewhere, and I wonder why they chose not to go that far.
try {throw new Error('')} // exception is caught
try {throw new Error('')} // uncaught exception
finally {console.log('finally')}
It seems like this code in Ruby:
```
begin
do_something
handle_error e
log_something
```
is equivalent to this in JavaScript:
```
try {
doSomething();
handleError(e);
logSomething();
```
I'm not saying that they're 100% equivalent, but I was thinking of the `try` block as if it's `rescue` when really it has more in common with `begin` in Ruby in that it's defining a block of code that can be rescued/caught if an error occurs.
So I guess my confusion comes from this type of block being named `try` rather than something like `do` or `begin`.
TL;DR I was just thinking about this in the wrong way from what I can tell.
EDIT: Yet I think that my point might still stand in that, if `try` is just a block that has its own scope, like an if-block or `begin` in Ruby, then it should be possible to not require either `catch` or `finally` since its own behavior has little to do with error handling.
For instance, this is possible:
```
let x = 'foo';
try {
let x = 'bar';
// noop
console.log(x); // foo
```
The try-block would be way more useful if it could just define scope without being tied specifically to error handling. There are lots of circumstances where defining scope would be handy outside of conditionals and creating functions for a similar purpose.
I guess what might have made the most sense, if JS could have started over, is that there'd be no `try` statement and that `do` could be used in its place.
```
const words = ['foo', 'bar', 'baz'];
let i = 0;
do {
console.log(words[i]);
i++;
console.error('whoops!');
```
We can't go back now since JS, for good reasons, is remaining mostly backwards-compatible. But the ability to do the above without extra gymnastics would be pretty cool.
try foo() with | ex1 -> failWith "doh!"
let result = try compute() with ex1 -> failwith "doh!" | ex2 -> -1But overall, loving the direction JS is taking.
If only it was that easy. The weeks I’ve spent hunting down webpack specific bugs because the plugins don’t always quite work with typescript transformations and source maps...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
If people are sticking to an older browser, they will never have the functionality (this can somewhat be mitigated through transpiling using Babel, but this isn't foolproof).
It often takes years for a feature to be widely deployed enough that no tranpiling is required. There are still features from ES2015 that I think still require transpiling.
So this is basically a fantasy what javascript could be no different than any other alt-js languages .
> Now the function would rather insert an escape character before the character code so that the result is still readable and valid UTF-8/UTF-16 code:
> JSON.stringify('\uD83D');
> // '"\\ud83d"'
I’m inclined to consider this a misfeature, unbreaking something that I’m glad was broken and should have remained broken.
Unpaired surrogates are (to simplify terminology a little) basically invalid Unicode. On the web platform, the only situation where unpaired surrogates should be encountered is as a transient state on user input, on platforms that send non-BMP characters through in two pieces (which is most browsers on Windows). Beyond that, nothing should ever deal in unpaired surrogates, because they will make things blow up and your life miserable.
Unpaired surrogates cannot be represented in UTF-8, or in well-formed UTF-16 (and that’s where JavaScript did the annoyingly bad thing that we’re paying for decades later, going with UTF-16 and not requiring well-formedness). Hence I’d quibble with the description of the result as “valid UTF-8/UTF-16 code”. (Sure, the actual JSON byte stream will be valid, but it contains an escaped string that is not valid.) U+FFFD REPLACEMENT CHARACTER was at least as valid, arguably more valid.
Various JSON parsers will choke on such strings, as observed in what I’d consider the canonical JSON spec: https://tools.ietf.org/html/rfc7159#section-8.2.
In the I-JSON restricted subset, which is what I’d say everything should actually limit itself to, such strings are disallowed and will cause parse failure: https://tools.ietf.org/html/rfc7493#section-2.1.
That is, formerly U+D83D would pass through straight as U+D83D (or possibly be replaced by U+FFFD in some implementations), whereas it is now "encoded" as the sequence U+005C U+0075 U+0044 U+0038 U+0033 U+0044.
That is, the entire point of the "well-formed stringify" proposal[1] was to stop generating broken JSON:
> Rather than return unpaired surrogate code points as single UTF-16 code units, represent them with JSON escape sequences.
[0] it's possible that some implementations would replace the lone surrogate by U+FFFD but according to MDN:
> Before this change JSON.stringify would output lone surrogates if the input contained any lone surrogates; such strings could not be encoded in valid UTF-8 or UTF-16
this is also the behaviour I observe on an old safari, and the one which is quoted in the tc39 proposal[1]:
> JSON.stringify can return strings including code points that have no representation in UTF-8 (specifically, surrogate code points U+D800 through U+DFFF). And contrary to the description of JSON.stringify, such strings are not "in UTF-16" because "isolated UTF-16 code units in the range D800₁₆..DFFF₁₆ are ill-formed" per The Unicode Standard, Version 10.0.0, Section 3.4 at definition D91 and excluded from being "in UTF-16" per definition D89.
The article does contain an error here, for the code point on the page is actually U+FFFD, not U+D83D (which of course is unrepresentable there). I trusted that (being a little surprised that it’d do the replacement, which is more what I’d expect of Python, but accepting it all the same) and didn’t pull out an old browser to confirm what actually happens, which is, as you say, an unpaired surrogate code point.
The article should probably say '"\ud83d"' instead of '"�"' (even though the number of backslashes still then requires thought), because yielding U+FFFD there would be a completely valid (and preferable, in my opinion) solution.
One thing I'd to request is that `Object.fromEntries()` simply skip undefined entries, rather than do...strange things. I wrote an `mapObject` function that looks like `(a,fn) => Object.fromEntries(Object.entries(a).map(fn))` and occasionally the fn needs to skip an entry and the easiest way to do this is just return `undefined`.
Not sure what strange things it does. fromEntries simply takes each entry, sets its first item as key (stringifying if necessary as object keys are necessarily strings) and the second item as value. Naturally falls from these that a null or undefined entry will error, and an empty entry will create an {undefined: undefined} item.
> I wrote an `mapObject` function that looks like `(a,fn) => Object.fromEntries(Object.entries(a).map(fn))` and occasionally the fn needs to skip an entry and the easiest way to do this is just return `undefined`.
Use flatMap instead?
``` let p = (a,fn) => Object.fromEntries(Object.entries(a).map(fn)) p({a:1, b:2}, ([k,v])=> v === 2 ? undefined : [k,v]) ```
My intent is to skip the entry with `b:2`. However, both map and flatMap error out. It would be nice if `fromEntries` did what I think is the appropriate thing, which is just skip undefined and null. Is this not the behavior you'd expect?
Note that without special treatment in fromEntries, there's no way for the mapping function to indicate "skip this entry". You have to do it in another pass, or some other way.
Trying to retroactively fixing bugs in code that did not follow the standard is not a good idea IMHO.
It was actually proposed by the v8 / chrome people (https://v8.dev/features/stable-sort) after they'd finally come around to implement one of the oldest v8 feature requests: https://bugs.chromium.org/p/v8/issues/detail?id=90
And stable does make for a better default than unstable: it offers stronger guarantees and more reliable behaviour. That's doubly important because by and large developers work to the implementation not the spec. And it's unlikely you'll ever change that.
The last one to switch was Chakra (Edge), and that one was weird as it used a stable sort up to 512 elements, and unstable above.
Funnily enough, Mozilla had originally switched to a stable sort because MSIE used a stable sort: https://bugzilla.mozilla.org/show_bug.cgi?id=224128
For example `Object.fromEntries(new URLSearchParams(window.location.search))` will parse a query string into a nice JS object. This works because the iterator of the search params class returns tuples.
What is already available today is `new URLSearchParams(Object.entries(params))` for turning a "params" object into a query string.
I wonder if Java will get pattern matching before JS https://medium.com/better-programming/top-5-new-features-exp...
Not sure how how much backwards compatibility this would break, but at some point we must allow for newer better less error-prone versions of the language to co-exist in different modules. That is not difficult at all. Consider the case of "use strict"; which does just such a thing. We could have "use strict 2020" etc.
(An alternative to String.prototype.trimStart would be to use String.prototype.replace, although trimStart would probably be more efficient.) Still some things missing includes: a goto command, ability to disable automatic semicolon insertion, macros, enhanced regular expressions, and a built-in regular expression quotation function (it is easily enough to implement in JavaScript, but it seem to me the kind of thing that should be built-in).